sexta-feira, 8 de novembro de 2013

Instalando aplicativos no Haiku (na nova hierarquia de pastas)

Traduzimos um pequeno tutorial disponibilizado pelo Humdinger no fórum do Haiku explicando de maneira simples como instalar aplicativos no Haiku R1A4 com Package Manager (PM). Como a criação do PM obrigou à substituição de algumas pastas de sistema, bem como a alteração de acesso de outras, este tutorial é bastante útil tanto para entender como instalar os aplicativos em si, como dá uma fórmula simples de como empacotar usando o novo formato .hpkg.

Instalando aplicativos


Com a recente incorporação do gerenciador de pacotes (obtenha uma nightly image e verifique) algumas coisas mudaram com respeito a instalação de aplicativos. Veja bem, tudo ainda está em evolução, com erros sendo encontrados e corrigidos e funcionalidades sendo refinadas (este artigo foi escrito para a versão hrev46218). Também, tenha em mente que não estou pessoalmente a par das funcionalidades do gerenciador de pacotes. Apreciarei correções, complementos e dicas!

Uma vez que os repositórios e pacotes estejam disponíveis e o HaikuDepot esteja mais completo em recursos, as coisas ficarão mais fáceis. Mas, até lá, eis como entendo as coisas. Existem basicamente três cenários:


1. Um novo pacote .hpkg correspondente

Se instalado automaticamente via HaikuDepot, por exemplo o WonderBrush, ou baixado de algum site. Ao usar o HaikuDepot, tudo estará configurado. Se baixar algo mais, apenas mova o arquivo .hpkg para dentro de ~/config/packages/ e (no caso de um aplicativo) ele aparecerá em ~/config/apps/.


2. Um “velho” arquivo autônomo

Estes vem tradicionalmente de sites como BeBits ou Haikuware na forma de uma pasta zipada. Como antes, você pode descompactar em qualquer lugar em /boot/home/ (exceto ~/config/ que é apenas leitura) e carregar o aplicativo do mesmo jeito que fazia antes do gerenciador de pacotes.


3. Um “velho” arquivo compactado que tem arquivos para espalhar

Este é o caso onde você costumava descompactar o arquivo em qualquer lugar e tinha que executar um script de instalação ou copiar alguns arquivos para locais especiais. Pensem em protetores de tela, tradutores e coisas semelhantes. Uma vez que a hierarquia do sistema de arquivos foi ligeiramente alterada e algumas pastas tornaram-se apenas leitura, aqueles aplicativos não mais funcionam facilmente. Você tem duas escolhas para fazê-los funcionar:


3.1 A pasta non-packaged

Em ~/config/non-packaged/ você pode recriar a hierarquia de arquivos necessária. Tomemos como exemplo a muito conveniente ferramenta TextBank, que oferece um histórico e modelos da área de transferência. Após descompactá-la para ~/config/non-packaged/apps/ você pode carregar o TextBank, mas ele ainda não fará nada. Os adicionais input_server TextBankAssistantPasteSender e TextBankAssistantSpy não estarão ainda no lugar certo no sistema de arquivos e portanto não serão carregados pelo sistema.

O TextBank se oferece para instalar aqueles arquivos em suas preferências, mas desde a mudança de hierarquia por causa do gerenciamento de pacotes, isso não funciona mais. Você terá que fazer isso manualmente, criando as pastas necessárias e copiando o arquivo correspondente:


~/config/non-packaged/add-ons/input_server/devices/TextBankAssistantPasteSender

~/config/non-packaged/add-ons/input_server/filters/TextBankAssistantSpy


Na próxima vez que reiniciar (ou restartar o input_server pelo Terminal com “/system/servers/input_server -q”) ele deverá funcionar.


3.2 Fazendo-o dentro de um pacote .hpkg correspondente

O método da pasta non-packaged é um pouco incômodo se você está atualizando seu sistema do zero frequentemente. Eis como criar um .hpkg do TextBank:

Crie uma pasta qualquer “PastaQualquer” e acrescente nela as subpastas “apps”, “add-ons/input_server/filters/” e “add-ons/input_server/devices/”.

Então descompacte o arquivo TextBank em “apps” e mova "TextBankAssistantPasteSender" e "TextBankAssistantSpy" para as pastas correspondentes recém-criadas.

Agora, a parte mais difícil, você tem que criar o arquivo de texto “.PackageInfo” na pasta pai “PastaQualquer”. A sintaxe exata desse arquivo é descrita na wiki do PM. Além disso, arquivos .hpkg abertos no Expansor (marque “Mostrar Conteúdo”) pode ser educativo. Ele mostrará algo assim:


name                    textbank_x86
version                 5.3.2-1
architecture            x86_gcc2
 
summary                 "A tool to provide clipboard history and more"
description             "Useful text provision tool (Clipboard history/template/time & date...)"
 
packager                "Humdinger "
vendor                  "SHINTA"
 
copyrights              "SHINTA"
licenses                "MIT"
 
provides {
                        textbank_x86 = 5.3.2-1
}
 
Observe, a licença é na verdade Creative Commons, mas este não existe ainda em /system/data/licenses/.
Você pode criar a sua própria, naturalmente, mas isso nos desviaria deste exemplo educativo.
Espero que SHINTA não exista... :)
Finalmente, vamos criar o arquivo .hpkg em si. Abra um Terminal em “PastaQualquer” e digite:
 
package create -b textbank.hpkg
 
Isso cria um pacote vazio com apenas o .PackageInfo. Continue com:
 
package add textbank.hpkg apps add-ons
 
E voilá! Ponha-o dentro de ~/config/packages para instalar e o TextBank irá aparecer em ~/config/apps/.

quarta-feira, 6 de novembro de 2013

Novidades do WebPositive [2]

Adrien Destugues, aka Pulkomandi, continua trabalhando duro na atualização do WebKit e consequentemente no WebPositive. Com o contrato firmado mês passado, ele está completamente dedicado a esse trabalho e já conseguiu avançar bastante na atualização do navegador nativo do Haiku. Segundo seus relatos, encontrados na blogosfera da página oficial do Haiku, ele já conseguiu conferir ao Web+ a capacidade de memorização de cookies, acesso a páginas como Outlook.com e mail.google.com, entre outros. Também houve relato de conseguir acessar web chat e outras funcionalidades não encontradas nas versões anteriores do Web+.
Entretanto, a versão de testes disponibilizada ainda apresenta alguns bugs na autenticação HTTP, fora outros possíveis problemas não relatados. Portanto, é importante colaborar com o trabalho do Adrien, baixando o novo Web+ e testando num nightly build mais recente possível.

CMake, Ninja e outras ferramentas
Para poder desenvolver seu trabalho, Pulkomandy teve que portar versões atualizadas do CMake (no lugar do Jam, para compilar o WebKit), do Ninja (uma ferramenta de tempo de execução simples e rápida), além de realizar diversas alterações em componentes de sistema, como o Services Kit, o Network Kit e Shared Kit, especialmente no suporte a regex. Todo o trabalho está sendo documentado e está sendo construída uma grande colaboração no Haiku Book através desse esforço.
No fim das contas, apesar do imenso trabalho, os frutos são significativos para todos, usuários e desenvolvedores.

quinta-feira, 24 de outubro de 2013

Haiku R1 deve ter nova release candidate nas próximas semanas

Após diversas discussões sobre se a próxima versão do Haiku seria um beta, ao que parece teremos mesmo um novo alfa. Esta semana, Niels publicou na lista de discussão dos desenvolvedores uma chamada para candidatos a gerente de release para o que deve ser o Haiku R1 Alpha 5. As características exigidas para os candidatos encontram-se descritas na própria mensagem e também no Wiki dos desenvolvedores do Haiku.
Segundo a nota, após o merging do ramo do Package Manager no tronco de desenvolvimento principal do Haiku, estima-se que em duas semanas o mesmo entre no modo release. O lançamento do suposto Alpha 5, porém, é estimado para janeiro do ano que vem.
Este anúncio acontece um mês depois da suposição publicada por Humdinger de que a partir do BeGeistert 027, realizado em setembro passado, teríamos ainda este ano o lançamento da versão beta e, em 2014, a tão aguardada versão final.

E o Beta?
Anteriormente, tinha-se como milestone para o lançamento da versão beta justamente a conclusão dos trabalhos em cima do PM. Entretanto, após uma série de discussões envolvendo as limitações técnicas do navegador Webpositive, especialmente a falta de suporte ao HTML5, definiu-se para o beta a resolução desse e de outros problemas de usabilidade do sistema. Como acordado há vários anos pelos desenvolvedores, uma versão final do Haiku só pode ser lançada quando o sistema estiver pronto para ser utilizado em produção por usuários finais. E é bastante conhecido da comunidade o quanto os desenvolvedores são rígidos quanto a essa premissa. Não é à toa que, mesmo depois de 12 anos de desenvolvimento, o Haiku ainda esteja em fase alfa.
Enquanto o novo alfa não é lançado, os colaboradores da comunidade podem ir experimentando, através das nightly builds, o gostinho do Haiku com o PM que, segundo os desenvolvedores, está recebendo refinamentos para começar a funcionar plenamente com os HaikuDepots a partir da nova versão. No momento, já é possível instalar alguns aplicativos atualmente disponíveis nos Depots oficiais.

Novidades do WebPositive

O navegador web do Haiku, WebPositive ou Web+, deve apresentar grandes novidades nos próximos meses. PulkoMandy anunciou em seu blog que voltou a dedicar-se "full time" ao desenvolvimento do Haiku e está particularmente trabalhando com o navegador, juntamente com o Hamish Morrison, autor do porte do OpenJDK para o Haiku durante o Google Summer of Code de 2012.
Muitas das observações colocadas por PulkoMandy foram rebatidas pelo Stephan Aßmus (Stippi), especialmente sobre as supostas limitações do cURL e entendimento geral de PulkoMandy sobre a relação Web+/Services Kit/WebKit. Stippi foi responsável, no passado, pela manutenção do Web+.

quinta-feira, 22 de agosto de 2013

Fórum do GUH-BR

Este é o ícone da página do fórum do Grupo de Usuários Haiku - Brasil, que está no ar a partir de hoje! Trata-se de mais um espaço de interação da comunidade haikusiasta do Brasil, onde poderemos tirar dúvidas, compartilhar conhecimentos e dicas, divulgar eventos, etc. Acesse-o a partir do menu no lado direito da página e faça parte desta história! Be different!

terça-feira, 20 de agosto de 2013

Não é apenas pelo dinheiro: Kickstarter para o Haiku

Recentemente começou uma longa discussão no fórum da página oficial do Haiku sobre lançar (ou não) uma campanha no Kickstarter para angariar fundos para o projeto. Entre as argumentações, a necessidade de acelerar o desenvolvimento, a difusão, a criação de uma "HaikuBox", entre outras sugestões. Particularmente, concentrei minha atenção nas colocações do Ryan Leavengood, tesoureiro da Haiku, Inc. Ele expressou que já havia pensado no assunto há algum tempo, mas precisava amadurecer algumas questões, como qual projeto desenvolver para atrair investidores que ainda não usam/conhecem o Haiku, qual o montante a angariar, como divulgar a campanha para o público potencial, etc.
A discussão também trouxe à tona algumas informações que geralmente são desconhecidas inclusive da comunidade não envolvida em desenvolvimento: os valores envolvidos nos contratos de dedicação exclusiva ao Haiku, pagos pela Haiku, Inc.; a motivação (ou não) dos desenvolvedores para assumir contratos dessa natureza; o porquê de não contratar desenvolvedores externos para estas tarefas, etc.
Resumo da ópera: a questão não é apenas dinheiro. A Haiku, Inc. possui recursos em caixa para sustentar mais dois contratos de exclusividade até o fim do ano, já agendados e previstos. As arrecadações feitas através do Bounty são suficientes para as necessidades atuais do projeto, no ritmo em que se encontra. Naturalmente que com mais dinheiro e desenvolvedores dispostos a dedicar mais tempo, as coisas acelerariam muito mais.
A respeito de uma possível "HaikuBox", muitas sugestões foram levantadas, especialmente mini-pcs com processadores Intel Atom ou ARM que servissem como servidores multimídia. Uma das sugestões que mais agradou foi o encapsulamento de uma placa Raspberry Pi numa case com a logo do Haiku. O grande problema em desenvolver um hardware dessa natureza está no desenvolvimento recente e, portanto, incipiente da versão do Haiku para a plataforma ARM. O Alexander von Gluck está encabeçando o subprojeto, aparentemente sozinho, e vem realizando progressos lentos, principalmente por conta da proximidade da versão beta para a plataforma Intel x86.
O fato é que ser desenvolvedor/colaborador do Haiku é uma questão mais de paixão pelo SO: no último contrato firmado, Ingo e Oliver acordaram um valor de EUR 2.000 por 160 horas de trabalho, o que dá EUR 12,50 por hora trabalhada. Num ambiente de recessão e altos impostos que vigora hoje na Europa, é um valor baixo, segundo Leavengood. Para comparar, ele mesmo recebe seis vezes esse valor por hora em contratos de trabalho nos Estados Unidos, desenvolvendo em Ruby on Rails.
Campanhas para o Kickstarter, a exemplo do que aconteceu com o Ubuntu Edge, precisam ser bem dimensionadas, factíveis, oferecer um produto que atenda ou supere as expectativas dos doadores e sejam entregues no prazo acordado. Com uma equipe pequena de desenvolvedores, fica difícil defender prazos mesmo que se tenha muito dinheiro em mãos. São bastante comuns os casos de projetos que conseguiram os valores almejados mas que não concluíram o produto, seja por mal dimensionamento dos custos, seja por falta de capacidade da equipe de desenvolvedores em entregar o produto no prazo. Deixar os doares na mão é um péssimo negócio para projetos com comunidade pequena, como é o caso do Haiku.
Esta semana conversei por e-mail com o Stephan Aßmus (aka Stippi), um dos principais desenvolvedores do Haiku e que possui uma empresa, a DramaQueen Gmbh, que desenvolve um aplicativo gerador e gerenciador de roteiros para cinema, sobre o porque do DramaQueen não possuir um porte para o Haiku. Para exemplificar, há cerca de um mês foi lançada uma versão do aplicativo para Linux. Segundo Stippi, o DramaQueen é desenvolvido utilizando o SWT do Eclipse, uma API Java que não possui suporte no Haiku. Apesar do porte feito no ano passado do OpenJDK, o suporte a Java no Haiku ainda não é completo e possui alguns problemas que o inviabilizam nas recentes nightly builds. É possível desenvolver para Java e rodar alguns aplicativos básicos usando o pacote developmentjava do installoptionalpackage, mas é só. Aplicativos mais robustos, como o próprio DramaQueen e o Storybook (voltado para escritores de livros), dependem de um suporte maior do Java para rodar redondo no Haiku.
Voltando à discussão inicial, Leavengood também tocou num assunto importante: o visual da interface gráfica do Haiku. Ele compartilha da mesma opinião de alguns usuários e simpatizantes: o visual retrô do Haiku afasta os novatos. Uma facelift do Rastreador (que, em última instância, é o "gerenciador de janelas" do sistema) seria mais do que bem vinda, acompanhada de um suporte nativo a composite - e junto com ele, transparências.
Eu acredito no grande potencial do Haiku em ser um poderoso sistema operacional para estação de trabalho gráfica e de multimídia, assim como seu concorrente histórico, o MacOS. Após o lançamento da versão R1 final, tudo indica que o desenvolvimento se voltará para a plataforma Intel x86_64 e para o ARM, abraçando os atuais padrões de mercado. Ou seja, a modernização do sistema depende de atingir, primeiro, o grande objetivo de Michael Phipps ao criar o OpenBeOS, que era ter total compatibilidade binária com o BeOS R5. A tarefa está quase concluída, falta pouco.

Haiku: Gerenciador de Pacote – Fazendo as Coisas Certas

Na esteira do assunto do momento, que é o gerenciador de pacotes do Haiku, traduzimos o artigo do Phillipe Saint-Pierre para o Unixmen que trata sobre o assunto. Uma pequena introdução para que nos preparemos para o que vem por aí.

Haiku: Gerenciador de Pacote – Fazendo as Coisas Certas
Escrito por Phillipe Saint-Pierre em 11 de junho de 2013

A comunidade Haiku está vivendo um momento muito peculiar estes dias. Eles estão testemunhando a criação do seu Gerenciador de Pacote. Considerado geralmente como a última peça faltante antes do Beta, a Haiku, Inc. atribuiu recentemente dois contratos que permitem trabalho em tempo integral neste subprojeto.
Enquanto isso, aqui está uma apresentação de como se espera que funcione:
Primeiramente, para responder a uma potencial pergunta frequente (PFAQ?), não, não é reutilizar outro formato de pacote do mundo do código aberto. Seguindo a filosofia do Haiku (e do BeOS), eles fomentam fazer as coisas certas. «Teria sido mais rápido» não é um argumento válido aqui. Realmente, várias decisões teriam sido tomadas diferentemente se fosse apenas considerado o tempo. Ao invés disso, uma solução baseada em sistema de arquivos foi criada, sendo tanto elegante como simples.
Então, como o Gerenciador de Pacote trabalha? É bastante simples. Como muitos sistemas, o Haiku permite processos para observar o conteúdo de certos diretórios. Assim, o Gerenciador de Pacote observa o conteúdo de muitos diretórios predeterminados e recebe eventos quando arquivos são adicionados ou removidos deles. Você colocaria o arquivo do pacote dentro de /boot/common/packages para uma instalação para o sistema inteiro ou /boot/home/config/packages para uma instalação para usuário único (a propósito, este último pode não fazer muito sentido uma vez que o Haiku é ainda um SO monousuário, mas é uma evidência futura).
Então, quando um pacote é movido para dentro de um daqueles diretórios, o Gerenciador de Pacote toma nota. Ele olha se existem quaisquer dependências faltantes e o conteúdo é então virtualmente extraído dos diretórios adequados. Virtualmente sim, porque /boot/common é um ponto de montagem de um sistema de arquivos chamado packagefs e seu conteúdo é realmente a união do todos os arquivos de pacotes em seu subdiretório de pacote. Em outras palavras, em /boot/common você verá os arquivos contidos em todos os arquivos HPKG situados em /boot/common/packages, e o mesmo pode ser dito para /boot/home/config.
Este processo de instalação pode ainda ser feito manualmente ao colocar aqueles arquivos utilizando o explorador de arquivos (copiar-colar, baixar diretamente para aquela localização) ou com a ajuda de uma ferramenta. Ou seja, o “mecanismo atrás dos bastidores” é igual.
Também, como você pode adivinhar, para remover um pacote, pode-se simplesmente remover arquivo do pacote de seu diretório de “pacotes” (seja ao eliminar o arquivo ou movê-lo para outra pasta). O daemon do gerenciador de pacote gerenciará casos onde dependências que foram instaladas com o pacote removido já não são requeridas e oferecer para limpar seu sistema.
Se você está interessado em aprender mais sobre este novo Gerenciador de Pacote, a principal fonte de informação sobre a matéria é o Wiki. Lá, você encontrará links para o repositório onde o código está sendo trabalhado, as especificações do formato de arquivo e políticas sobre como construir um pacote. Ele já é testável e a lista de pacotes disponíveis está crescendo. Ele deve ajudar desenvolvedores externos a tentar portar seus softwares e empacotá-los para o Haiku.

Fonte: Unixmen