TL; DR : O Haiku é um sistema operacional projetado especificamente para PCs, portanto, existem alguns truques para tornar seu ambiente de trabalho muito melhor do que outros. Mas como isso funciona?
Eu descobri recentemente o Haiku, um sistema inesperadamente bom. Ainda se surpreende com a facilidade de funcionamento, especialmente se comparado aos ambientes de desktop Linux. Hoje olho sob o capô. Onde for necessário para um entendimento aprofundado, farei uma comparação com os ambientes de trabalho originais para Macintosh, Mac OS X e Linux (padrão XDG de freedesktop.org).
Recursos em arquivos ELF
Ontem, eu aprendi que o IconOMatic pode salvar ícones nos recursos rdef nos executáveis do ELF. Hoje eu quero ver como ele realmente funciona.
Recursos? Uma citação de Bruce Horne , o autor original do programa Macintosh Finder e o "pai" do Macintosh Resource Manager:
Estou preocupado com a natureza difícil da escrita tradicional de código. Para mim, a própria idéia de um aplicativo congelado no código, sem a capacidade de alterar qualquer coisa dinamicamente, é a natureza mais selvagem. Deve ser possível alterar o máximo possível no estágio de tempo de execução. Obviamente, o código do aplicativo em si não pode ser alterado, mas algo pode ser alterado sem recompilar o código?
No Macintosh original, eles fizeram com que esses arquivos tivessem uma “seção de dados” e uma “seção de recursos”, o que tornava extremamente fácil salvar várias coisas, como ícones, traduções, etc. em arquivos executáveis.
No Mac, o ResEdit é usado para isso, um programa gráfico para - de repente - editar recursos.
ResEdit no Macintosh original
Como resultado, tornou-se possível editar ícones, itens de menu, traduções etc. fácil, mas eles ainda "viajam" com os aplicativos.
De qualquer forma, essa abordagem teve uma grande desvantagem: funcionou apenas nos sistemas de arquivos da Apple, que foi um dos motivos pelos quais a Apple abandonou a "seção de recursos" ao mudar para o Mac OS X.
No Mac OS X, a Apple queria uma solução independente do sistema de arquivos, e aplicou o conceito de pacotes (da NeXT), diretórios que o gerenciador de arquivos trata como "objetos opacos", como arquivos, não diretórios. Qualquer pacote com um aplicativo no formato .app possui, entre outras coisas, um arquivo Info.plist (em algum análogo de JSON ou YAML da Apple) contendo metadados do aplicativo.
Chaves para o arquivo Info.plist do pacote de aplicativos do Mac OS X.
Recursos, por exemplo, ícones, arquivos de interface do usuário e outros, são armazenados no pacote como arquivos. O conceito, na verdade, voltou ao básico no NeXT.
Mathematica.app no NeXTSTEP 1.0 em 1989: exibido como um diretório com arquivos no terminal, mas como um único objeto em um gerenciador de arquivos gráfico.
De volta ao BeOS, no qual o Haiku se baseia. Ao passar do PEF (PowerPC) para o ELF (x86) (o mesmo usado no Linux), seus desenvolvedores decidiram adicionar uma seção de recursos ao final dos arquivos ELF. Para isso, nossa própria seção ELF adequada não foi usada, ela foi simplesmente anexada ao final do arquivo ELF. Como resultado, o programa de strip e o resto dos binutils, que desconheciam isso, simplesmente o interromperam. Portanto, adicionando recursos ao arquivo ELF no BeOS, é melhor não trabalhar com as ferramentas do Linux.
O que está acontecendo com o Haiku agora? Em princípio, mais ou menos o mesmo.
Em teoria, você poderia colocar recursos na seção direita do ELF. De acordo com 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 eles fizeram isso no BeOS "
E não vale a pena mudar agora.
Gerenciamento de recursos
Os recursos são gravados em um formato estruturado de "recurso": na verdade, esta é uma lista de recursos com tamanhos e, em seguida, seu conteúdo. Lembrei-me do formato ar .
Como verificar recursos no Haiku? Existe algo como ResEdit?
De acordo com a documentação :
Para visualizar os recursos fornecidos no pacote de aplicativos, você pode arrastar o arquivo executável para um programa como o Resourcer . Você também pode ir ao terminal e executar o comando listres _ .
Existe um pesquisador no HaikuDepot, mas para mim ele apenas trava.
Como gerenciar recursos em arquivos ELF? Usando rsrc e rdef . rdef arquivos rdef são coletados no rsrc . O arquivo rdef é armazenado em formato de texto sem formatação, portanto, trabalhar com ele é muito mais fácil. Um 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 verificar e gerenciar:
/> 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
Você pode ler mais sobre recursos e formato rdef 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 correspondência de arquivos abertos, inicialização, IPC etc.app_name_catalog_entry : como o nome do aplicativo geralmente está em inglês, aqui você pode especificar onde estão os nomes traduzidos, para que usuários de diferentes idiomas vejam o nome do aplicativo traduzido, se desejar.app_version : exatamente o que você pensouapp_flags : informa ao registrar como lidar com o aplicativo. Eu acho que há algo mais do que parece à primeira vista. Por exemplo, há B_SINGLE_LAUNCH , que força o sistema a iniciar um novo processo de aplicativo a cada vez, a pedido do usuário (o mesmo princípio é usado para a maioria dos aplicativos Linux). Há B_MULTIPLE_LAUNCH que força o início de um processo para cada arquivo . Por fim, existe o B_EXCLUSIVE_LAUNCH , que força o sistema a iniciar apenas um processo de cada vez, independentemente da frequência com que os usuários o iniciam (por exemplo, o Firefox também inicia no Linux; o mesmo resultado pode ser alcançado em aplicativos Qt usando a função QtSingleApplication ). Os aplicativos com B_EXCLUSIVE_LAUNCH notificados quando o usuário tenta executá-los novamente: por exemplo, eles obtêm o caminho do arquivo que o usuário deseja abrir com sua ajuda.vector_icon : Ícone de aplicativo de vetor (não havia ícones de vetor no BeOS, a maioria dos aplicativos tinha dois ícones de varredura em arquivos executáveis).
Obviamente, você pode adicionar recursos com quaisquer IDs e tipos desejados e lê-los no próprio aplicativo ou em outros aplicativos usando a classe BResources . Mas primeiro, vamos nos debruçar sobre o fascinante tema dos ícones.
Ícones do vetor no estilo Haiku.
Obviamente, não apenas o Haiku escolheu o melhor formato de ícone, nesta parte a situação nos ambientes de trabalho 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 do que é um pedaço.
Obviamente, existe um escalonável que contém, como você pode entender, ícones vetoriais. Por que então há mais alguma coisa? Como o resultado da renderização de gráficos vetoriais em tamanhos pequenos pode ser pior que o ideal. Eu gostaria de ter várias opções otimizadas para tamanhos diferentes. Nos ambientes de trabalho Linux, isso é conseguido espalhando ícones com tamanhos diferentes no 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
Atenção: não há conceito de versões diferentes do Firefox. Portanto, você não pode lidar sutilmente com a situação com a presença de várias versões do aplicativo no sistema.
Ícones diferentes do Firefox em diferentes versões. Ainda não é possível lidar com isso no Linux sem várias muletas.
O Mac OS X lida um pouco mais sofisticadamente:
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 há um arquivo firefox.icns no pacote Firefox.app contendo todos os tamanhos, portanto versões diferentes do mesmo aplicativo têm ícones diferentes.
Muito melhor! Os ícones viajam com o aplicativo, todos os recursos em um arquivo.
De volta ao Haiku. Uma decisão alucinante, sem exceções. De acordo com a documentação :
Um especial altamente otimizado para o formato HVIF foi desenvolvido para tamanhos pequenos e renderização rápida. Portanto, nossos ícones são em geral muito menores do que no formato raster ou SVG amplamente utilizado.
E eles são otimizados:
Tamanhos de ícone em HVIF em comparação com outros formatos.
A diferença é uma ordem de magnitude!
Mas a mágica não termina aqui. O mesmo HVIF pode mostrar diferentes níveis de detalhes, dependendo do tamanho exibido, mesmo que seja um formato vetorial.
Diferentes níveis de detalhe (LOD), dependendo do tamanho da renderização
Agora, sobre as deficiências: você não pode usar o SVG, soltá-lo no ImageMagick e terminar aí. Você precisa passar por vários ciclos para criar um ícone no formato HVIF. Aqui estão as explicações. No entanto, IconOMatic pode importar imperfeitamente SVG; cerca de 90% das peças SVG são importadas com alguma probabilidade, os 10% restantes precisarão ser ajustados e alterados manualmente. Você pode ler mais sobre como o HVIF faz sua mágica no blog de Lea Ganson.
Adicionando um ícone ao aplicativo
Agora posso adicionar um ícone ao pacote criado da última vez , levando em consideração todas as informações recebidas.
Bem, como não estou realmente ansioso para desenhar meu próprio ícone para o meu QtQuickApp "Hello World" - 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 está 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?
VICN copiado: 101: BEOS: ICONs ainda não é usado como um ícone para um aplicativo no gerenciador de arquivos
O que estou perdendo?
Comentário do desenvolvedor:
Você precisa criar um arquivo rdef com todos os recursos e, em seguida, execute o rc .rdef , isso criará um arquivo .rsrc . Então você precisa executar o resattr -o _ .rsrc . No mínimo, uso comandos semelhantes para adicionar ícones aos meus scripts.
Bem, eu queria criar um recurso, não um atributo. Estou diretamente confuso.
Cache inteligente do sistema de arquivos
A abertura e leitura dos atributos ELF é lenta. Como escrevi acima, o ícone é gravado como um recurso no próprio arquivo. Este método é mais confiável, permite sobreviver copiando para outro sistema de arquivos. No entanto, 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 no Deskbar) são lidos nesse atributo estendido, porque essa solução funciona rapidamente. Em alguns lugares (onde a velocidade não é importante, por exemplo, uma janela típica "Sobre"), o sistema recebe o ícone diretamente do recurso no arquivo. Mas este não é o fim. Lembre-se, em um Mac, os usuários podem substituir ícones de aplicativos, diretórios e documentos por seus próprios, pois em um Mac é possível fazer essas coisas "importantes", por exemplo, substituindo um novo ícone do Slack por um anterior . No Haiku, você deve considerar o recurso (no arquivo) como o ícone de origem que acompanha o aplicativo e o atributo (no sistema de arquivos BFS) como algo que permite ao usuário fazer as alterações desejadas (embora, uma dica, a interface gráfica para inserir o ícone do usuário na parte superior do ícone seja o padrão ainda não foi implementado).
Verificando atributos do sistema de arquivos
Com o resaddr , é possível verificar e definir os 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. (...)
Em essência, essa é uma "cola" que realiza a conversão entre os recursos (confiáveis) e os atributos (rápidos) do sistema de arquivos. E como o sistema assume o recebimento de recursos e executa a cópia automaticamente, não me preocuparei mais com isso.
Pacotes mágicos hpkg
Atualmente (na maioria das vezes) os pacotes .hpkg são usados para obter os .hpkg Haiku. Não se deixe enganar por um nome simples: o formato .hpkg funciona de uma maneira completamente diferente de outros formatos com nomes semelhantes que você encontrou, ele possui superpotências reais.
Com os formatos tradicionais de pacotes, fiquei chateado por muito tempo por esse fato: você baixa um (pacote) e outro é instalado no sistema (arquivos dentro do pacote). Já é difícil gerenciar arquivos (por exemplo, excluí-los) ao instalar o pacote da maneira tradicional. E tudo porque o conteúdo do pacote está espalhado por todo o sistema de arquivos , incluindo locais onde o usuário médio pode não ter acesso de gravação. O mesmo gera toda uma classe de programas - gerenciadores de pacotes . Porém, ao transferir o software já instalado, por exemplo, para outra máquina, um disco removível ou servidor de arquivos se torna ainda mais difícil, se não impossível. Em um sistema típico baseado em Linux, várias centenas de milhares a milhões de arquivos separados podem existir facilmente. Escusado será dizer que é frágil e lento, por exemplo, durante a instalação inicial do sistema, durante a instalação, atualização e remoção de pacotes regulares, bem como ao copiar um volume de inicialização (partição raiz) para outro meio.
Estou trabalhando no projeto AppImage, uma muleta parcial para aplicativos do 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 montada quando o aplicativo é iniciado. Isso simplifica bastante as coisas, pois o mesmo ImageMagick se transforma repentinamente em um único arquivo, gerenciado no gerenciador de arquivos por meros mortais. O método proposto funciona apenas para software, como refletido no nome do projeto, e também possui seu próprio conjunto de feridas, pois as pessoas que fornecem software para Linux sempre jogam suas flechas em mim.
De volta ao Haiku. Você conseguiu encontrar o equilíbrio ideal entre os sistemas de pacotes tradicionais e a entrega de software baseado em imagem? Seus pacotes .hpkg na verdade imagens do sistema de arquivos compactados. Quando o sistema é inicializado, 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, né? Espere, será ainda mais legal!
Há 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 mínimo, incluindo o kernel. Acredite ou não, mesmo o próprio kernel não é extraído do volume de inicialização (partição raiz), mas é cuidadosamente carregado no seu lugar a partir do pacote .hpkg . Uau! Eu já mencionei que, para mim, parte da sofisticação e coerência geral do Haiku se deve ao fato de que todo o sistema do kernel e do espaço básico do usuário, além do gerenciamento de pacotes e infraestrutura do ambiente de trabalho, é desenvolvido em conjunto por uma equipe. Imagine quantos grupos e comandos diferentes são necessários para executar um baseado em Linux como este [imagino um projeto PuppyLinux - aprox. tradutor] . Então imagine quanto tempo leva para que essa abordagem seja implementada nas distribuições. Eles dizem: faça uma tarefa simples, dividida entre diferentes artistas, e ela se tornará tão complicada que não será resolvida. Haiku, neste caso, abriu meus olhos. Eu acho que isso é exatamente o 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 a seguinte situação ocorre: a atualização foi bem-sucedida e, então, acontece que algo não está funcionando como deveria? Se você usar os gerenciadores de pacotes usuais, é difícil retornar o estado do sistema ao ponto no tempo antes de instalar novos pacotes (por exemplo, no caso em que algo deu errado). Alguns sistemas oferecem soluções alternativas na forma de capturas instantâneas do sistema de arquivos, mas são bastante complicadas e também não são usadas em todos os sistemas. No Haiku, isso é resolvido usando pacotes .hpkg . Sempre que os pacotes no sistema são alterados, os pacotes antigos não são excluídos, mas são armazenados no sistema em subdiretórios no formato /Haiku/system/packages/administrative/state-<...>/ permanentemente. Operações incompletas armazenam seus dados nos 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, "transação ..." - os próprios pacotes.
"Antigo estado ativo", ou seja, a lista de pacotes .hpkg ativos antes das alterações é gravada após cada operação no gerenciador de arquivos no arquivo de texto /Haiku/system/packages/administrative/state-<...>/activated-packages . De maneira semelhante, o novo "estado ativo" é escrito no arquivo de texto /Haiku/system/packages/administrative/activated-packages .
O diretório /Haiku/system/packages/administrative/state-<...>/ contém apenas um arquivo de texto com uma lista de pacotes ativos desse estado (se os pacotes foram instalados sem desinstalar) e se os pacotes foram excluídos ou atualizados, o diretório state contém versões antigas dos pacotes .
Quando o sistema é inicializado, com base na lista de pacotes, é tomada uma decisão para ativar (montar) os pacotes. Tão simples! Se algo der errado durante o download, você pode dizer ao gerenciador de downloads para usar uma lista diferente e antiga. O problema está resolvido!
Carregador de inicialização Haiku. Cada ponto de entrada exibe um "estado ativo" correspondente
Eu gosto da abordagem com arquivos de texto simples como uma lista do "estado ativo", no qual nomes .hpkg compreensíveis são .hpkg . Isso contrasta bastante com o heap OSTree ou Flatpak criado para máquinas, mas não pessoas no sistema de arquivos (o mesmo nível do Microsoft GUID).
Lista de pacotes ativos para cada momento
Dados de configuração
Aparentemente, o diretório /Haiku/system/packages/administrative/writable-files contém arquivos de configuração para pacotes, mas é gravável. Afinal, como você se lembra, o .hpkg é montado apenas para leitura. Portanto, esses arquivos devem ser copiados dos pacotes antes de serem gravados. Faz sentido.
Integração da GUI para o sistema .hpkg
Vamos agora ver como esses pacotes .hpkg brilhantes .hpkg com a integração no espaço de trabalho do usuário (UX). Afinal, o Haiku é destinado ao uso pessoal, afinal. Pessoalmente, defini um nível alto comparando a experiência do usuário com os pacotes .app no Macintosh com a mesma experiência no .hpkg . Nem vou comparar a situação com os ambientes de trabalho no Linux, porque é absolutamente terrível em comparação com outros.
Os seguintes cenários vêm à mente:
- Quero ver o conteúdo do pacote
.hpkg - -,
- -,
- , Haiku ( , .)
- (, ) , ( ) ( , , ).
. , .
Mac Finder. ! ( , .pkg , , ).
Haiku , "Contents" , . .
, () .hpkg , . ( , .hpkg Expander , ).
HaikuDepot , , , README.md
Mac , HaikuDepot .
GUI
Mac , .dmg .app . , , , /Applications Finder. , , . - Apple "" /Applications ( NeXT , ), $HOME/Applications , .
Haiku , , "Install", . , , , HaikuPorts, . Linux , , — , . , Haiku.
'sanity' , , ( , ). Linux .
— , .hpkg /Haiku/system/packages ( , -), /Haiku/home/config/packages ( ; — "config" , "settings"). Haiku (, — , , ).
Haiku, , .
GUI
Mac , , . !
Haiku , -, , , ( ). /Haiku/system/packages ( -), /Haiku/home/config/packages ( , "config" — ?). , .
! , . :
, /Haiku/system/packages
", " QtQuickApp. , — .hpkg " " . , "", -.
mr. waddlesplash :
10 . , . .
, , , HaikuDepot? /Haiku/system/packages , , "Uninstall". -, () «Install». «Uninstall», ?
, , "Install" . :
, .
:
"Apply changes" —
, , . [ , — . tradutor]
: "Uninstall", /Haiku/system/packages , /Haiku/home/config/packages .
, HaikuDepot, .
Mac. , Haiku , Mac. ( : " HaikuDepot, ++", ?)
-
, .hpkg , (, " " - ).
Mac , .dmg , .app . .dmg , /Applications . , , , Apple. ( , Mac. , , AppImage , . = . !)
Haiku , apps/ packages/ , , . , apps/ :
, .hpkg
( , ), .
: GUI .hpkg
, Alt+D. " ". , /system ( /system/packages /system/settings ) packagefs (, df ?). , mount ( ), mountvolume ( loop .hpkg ""), .
, AppImage ( , , ). , , Haiku , Mac.
: , "" «». , "" «": , ( , , ). ?
Mac , .app , — .
Haiku , , .
: ```.hpkg , , .
Mac. , . Haiku .hpkg , ...
. , (, , Windows, Mac Linux) . , -, , , [ , Windows… — . ].
, , Windows Linux.
Mac , — .dmg . , , MacOS -. , , java.
Haiku .hpkg , , java, , java , . .hpkg , , Haiku - , , Haiku?
Mac.
mr. waddlesplash:
, .hpkg -, Haiku, 15 . , . .
.
, .hpkg (, ) , ( ). ( ) — , () , . , .
Mac .app Finder, . . !
Haiku , , .hpkg , , . , , GUI.
Mac.
mr. waddlesplash:
. , , . .
.
: ( LAN ) , , (, Zeroconf), . , app_flags .
hpkg c GUI
, - .hpkg GUI . , , UX...
: Kernel Debug Land
kernel panic , syslog | grep usb . , Haiku Kernel Debug Land. , kernel panic? , Alt+PrintScn+D ( Debug). Programmer's Key , Macintosh ( , ).
Conclusão
, Haiku , .
Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, , .
, .hpkg , Snappy, Flatpak, AppImage, btrfs, " " Mac.
- "" , , .hpkg , — . , . Mac.
, , , ( Gtk, Electron — , ), 3d , . . , , .
, Haiku .
, ?
- BeScreenCapture GIF, Peek. ffmpeg, Haiku. .
- ,
- WonderBrush, —
- Haiku, , . Krita, (. ). . .
Tente você mesmo! Afinal, o projeto Haiku fornece imagens diárias de download de DVD ou USB. Para instalar, basta baixar a imagem e gravá-la em uma unidade flash USB usando o Etcher
Tem uma pergunta? Convidamos você para o canal de telegrama em russo.
Visão geral do bug: Como dar um tiro no pé em C e C ++. Coleção de receitas do sistema operacional Haiku
Do autor da tradução: este é o sexto artigo da série Haiku.
Lista de artigos: Primeiro Segundo Terceiro Quarto Quinto Sexto Sétimo Oitavo Nono