BSD Magazine é uma revista mensal de excelente qualidade técnica, visual e gratuita para todo e qualquer profissional que queira ficar bem informado sobre tecnologia e informação utilizando BSD e outros Softwares Livres.

A revista encontra-se em idioma Inglês e para baixá-la basta informar o seu e-mail e clicar para baixar. Todas as outras edições anteriores também podem ser baixadas. Seu formato está em pdf.

Conteúdo:

O fato do PC-BSD ter uma instalacão fácil, intuitiva e agradável é sim um fato importante para sua popularizacão. Ser um sistema estável, de alta performance e seguro claramente não é suficiente para sua popularizacão em ambiente Desktop. Já, ser de fácil uso e ter um resultado rasoável por padrão após a instalacão, também é muito relevante para o perfil de usuários que o PC-BSD se destina: o usuário doméstico típico.

Porém, um dos principais fatores de destaque do PC-BSD no que tange a facilidade de uso é o seu sistema de instalacão de aplicacões de terceiros, o PBI: Push Button Installer, ou Instalador ao Apertar do Botão. O PBI é um formato especial e exclusivo do PC-BSD. Apesar de podermos usar pacotes pré-compilados (pkg_add) ou compilar a aplicacão localmente com a Colecão de Ports do FreeBSD, o formato padrão não é nenhum dos dois, e sim o PBI, que analisaremos agora em mais detalhes.

O Formato PBI – Visão Superficial

O formato de pacotes do instalador PBI é simples, parte do princípio que um PBI vai sempre instalar a aplicacão, todas as bibliotecas e dependências dessa aplicacão, em um compartimento único e isolado. Dessa forma não há conflitos de bibliotecas, não há também conflitos entre versões de dependências, nem há dependência da própria ABI nativa do sistema operacional.

A idéia por trás do conceito que o PBI trás é de um instalador que vai instalar aplicacões que vão rodar em qualquer versão do PC-BSD, e principalmente, que vai continuar plenamente funcional mesmo após atualizacões mesmo as mais radicais, com troca plena de ABI, com tanto que uma compatibilidade mínima seja mantida entre o sistema novo e suas versões anteriores – em kernel, os COMPAT_FREEBSD4, COMPAT_FREEBSD5, COMPAT_FREEBSD6, COMPAT_FREEBSDX;

Para isso, os arquivos com extensão .pbi são interpretados pelo PC-BSD como instalacão e são considerados executáveis. Esses executáveis são divididos essencialmente em quatro partes:

A primeira é a biblioteca de carregamento (o loader) que permite que o .pbi seja interpretado como um executável ELF. Ou seja são os Elf Loader Headers. A segunda parte contém embarcado o ícone da aplicacão que será instalada. A terceira camada tem as directivas e dados de configuracão do .pbi que identificam o que, onde e como será instalado. E finalmente a quarta etapa, são todos os dados da aplicacão, biblitecas e dependências, bem como os scripts que serão instalados.

O produto final de um arquivo .pbi é um executável auto-instalável:

eksffa@pcbsd% file JavaJRE1.6.0-PV0.pbi
JavaJRE1.6.0-PV0.pbi: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.0 (700109), dynamically linked (uses shared libs), FreeBSD-style, not stripped

eksffa@pcbsd% brandelf ./JavaJRE1.6.0-PV0.pbi
File ‘./JavaJRE1.6.0-PV0.pbi’ is of brand ‘FreeBSD’ (9).

Que de fato, é linkado dinamicamente apenas a própria ABI nativa (libc):

eksffa@pcbsd% ldd ./JavaJRE1.6.0-PV0.pbi
./JavaJRE1.6.0-PV0.pbi:
libc.so.7 => /lib/libc.so.7 (0x2807e000)

E cujo prefix de instalacão é fora do padrão FreeBSD, quebra a hier(7) e também a especificacão POSIX, e fica isolado em /Programs, não tocando qualquer outro arquivo em infra-estrutura fora dessa hierarquia.

 

Entendendo o funcionamento de um Produto Instalado a partir de um PBI

Aqui chega a parte onde a abordagem por trás de um produto resultante de um PBI instalado deve ser avaliado e entendido. Os binários e bibliotecas criados de um PBI são exatamente iguais os criados da compilacão genérica de um Ports ou a instalacão de um package binários. O produto é o mesmo, mas sua estrutura instalada e a forma como são carregados, é a diferencão.

O coracão por trás do PBI é uma idéia simples, completamente funcional, mas com alguns efeitos colaterais. Todo binário já acompanha suas dependências e suas bibliotecas, e esses são isolados, e utilizados exclusivamente para aquela aplicacão.

A estrutura da instalacão de um PBI se baseia que tudo será instalado no /Programs (que por sua vez é um link simbólico para o /usr/Programs); e abaixo dele temos algumas estruturas, nem sempre todas utilizadas. A saber:

Programs/
Programs/bin/
Programs/lib/
Programs/etc/
Programs/rc.d/
Programs/rc.conf
Programs/<aplicacão>/

Todas aplicacões são instaladas em /Programs/<aplicacão>/, que é sempre constituído da seguinte organizacão hierárquica:

Programs/<aplicacão>/bin/
Programs/<aplicacão>/.sbin/
Programs/<aplicacão>/autolibs/
Programs/<aplicacão>/share/
Programs/<aplicacão>/libs (lincado para ./autolibs local)

Além disso temos sempre scripts executáveis:

Programs/<aplicacão>/PBI.FirstRun.sh
Programs/<aplicacão>/PBI.RemoveScript.sh
Programs/<aplicacão>/PBI.RemoveScript2.sh
Programs/<aplicacão>/PBI.SetupScript.sh
Programs/<aplicacão>/PBI.UpdateURL.sh

Os executáveis acima são rotinas executadas na primeira inicializacão da aplicacão depois de instalada, um script auxiliar que permite ao sistema de atualizacão de PBI avaliar se há atualizacões do PBI em questão, e por último os outros são rotinas de deinstalacão da aplicacão.

O mais importante é o:

Programs/<aplicacão>/autolibs/

 

Isso porque nessa estrutura estão todas, todas a bibliotecas de que o binário depende, bem como suas dependências, sejam essas bibliotecas ou aplicacões. Ou seja quando a aplicacão é executava, o contexto de bibliotecas dinâmicas do linker do loader (carregador) é isolado, e as bibliotecas disponíveis para aquele contexto de execussão é exclusivamente as que estivirem em Programs/<aplicacão>/autolibs/.

Inteligente não? Dessa forma não importa a ABI do sistema operacional, nem importa que bibliotecas existam ou não, que dependências existam ou não no restante do sistema, pois tudo que a aplicacão precisa, ela já “traz consigo”. Quase como se fosse um binário compilado estáticamente. Porém, não é estático, é dinâmico, e apesar de em disco haver redundância de bibliotecas, em memória os objetos iguais são sempre alocados em memória shadow, não havendo o mesmo consumo de memória que haveria se fossem todas aplicacões estáticamente compiladas.

O binário de inicializacão real (o verdadeiro produto da instalacão) fica disponível em:

Programs/<aplicacão>/bin/

Porém, o ambiente de execussão desse binário acontece através do que fica disponívem em:

Programs/bin/<aplicacão>

Que por sua vez é um link simbólico, que se referencia a um shell script disponível em:

Programs/<aplicacão>/.sbin/

E ai sim, esse shell script é onde fica a sacada, o pulo do gato do isolamento de contexto de bibliotecas. Vejamos um exemplo prático, o amsn instalado, instala um arquivo .desktop no Desktop, que é o link para a aplicacão, vejamos:

[Desktop Entry]
Name=aMSN
Exec=/Programs/aMSN0.97.2_1/.sbin/amsn
Type=Application
Path=/Programs/aMSN0.97.2_1/
Icon=/Programs/aMSN0.97.2_1/amsn.png

Ou seja ao clicar nesse ícone, é executado o  /Programs/aMSN0.97.2_1/.sbin/amsn, que por sua vez é um link simbólico para um shell script:

% ls -l /Programs/bin/amsn
lrwxr-xr-x  1 root  wheel  33 10 Dez 21:11 /Programs/bin/amsn -> /Programs/aMSN0.97.2_1/.sbin/amsn

 

 

O Executável de Inicializacão da Aplicacão

O shell script que faz o isolamento do contexto das bibliotecas dinâmicas e carrega a aplicacão pode ter algumas variacões, mas a essência geral é a seguinte:

A variável de ambiente LD_LIBRARY_PATH é populada, e seu único conteúdo é o Programs/<aplicacão>/autolibs/ ; com essa variável definida assim, o binário é executado em Programs/<aplicacão>/bin/<aplicacão>. Dessa forma qualquer biblioteca ou dependência que o binário precisa, só tem o Programs/<aplicacão>/autolibs/ onde carregar. Esse é o coracão por trás do ambiente instalado por um PBI.

Outros arquivos podem ser necessários, caso em que outras variáveis são populadas permitindo acesso as demais estruturas. Mas normalmente são apenas arquivos de referência de configuracão e comportamento, como share, ícones, configuracões padrão, diretivas de controle, etc.

Seguindo o estudo vamos analisar o que temos para iniciar o amsn:

#!/bin/sh
# Auto-Generated by PC-BSD
PATH=”/Programs/aMSN0.97.2_1/bin:$PATH”; export PATH
LANG=”`grep ^Language= ~/.kde/share/config/kdeglobals | cut -d “=” -f2`”; export LANG
LD_LIBRARY_PATH=”/Programs/aMSN0.97.2_1/autolibs/” ; export LD_LIBRARY_PATH
STDLOG=”${HOME}/.$$stdout”
STELOG=”${HOME}/.$$stderr”
(((( /Programs/aMSN0.97.2_1/bin/amsn  “$@” || /PCBSD/bin/CrashHandler “bin/amsn” “${STDLOG}” “${STELOG}” ) | tee $STDLOG) 3>&1 1>&2 2>&3 | tee $STELOG) 3>&1 1>&2 2>&3)

rm $STDLOG >/dev/null 2>/dev/null
rm $STELOG >/dev/null 2>/dev/null

É esse o esqueleto padrão. Podem haver variacões, e de fato a infra-estrutura do PBI permite que hajam, para satisfazer os todos possíveis perfis de necessidade de aplicacões. Mas as variacões são apenas uma repeticão da idéia geral acima.

Avaliacão da Abordagem PBI

As impressões sobre a abordagem acima são as mais variadas. Sobre o PBI, já tivemos opinião de desenvolvedores Red Hat que mantém o padrão RPM, já tivemos opiniões de empacotadores Debian acostumados com os formatos de pacotes do Debian e toda a (bem criteriosa e inteligente, diga-se de passagem) estrutura de pacotes do Debian, e a opinião de Port Managers do Projeto FreeBSD, bem como mantenedores do PkgSrc.

De forma geral todos acham a idéia inteligente, porém, inadequada. O motivo é claro, ninguém gosta de ver tamanha redundância de bibliotecas e dependências como os PBI instalam. Porém, todos concordam, que poucas abordagens tem resultado tão prático e funcional. E acima de tudo, essa é a única abordagem livre de conflitos e problemas de dependências.

Efeitos Colaterais

Pro usuário final, porém, as consequências negativas da abordagem do PBI são duas: os PBI de forma geral são maiores do que poderiam ser, o download tem que trazer junto todas as dependências e bibliotecas que, de certa forma, podem já estar presentes no autolibs/ de alguma outra aplicacão ou na própria base do sistema operacional.

A segunda consequência é o espaco em disco. A abordagem dos PBI ocupa muito mais espaco em disco exatamente devido a essa redundância de bibliotecas e dependências. Em minhas análises, um conjunto simples de aplicacões, Firefox, aMSN, OpenOffice e Java, o consumo de espaco em disco é 34% superior com PBI do que instalado por pacote (package) pré-compilado. Se comparado com aplicacões compiladas localmente e com grande nível de customizacão de Build Time a diferenca pode ser ainda maior.

Resultados Obtidos pela Abordagem PBI

Os resultados conseguidos com essa abordagem porém, são os melhores possíveis: facilidade de uso, efetividade, e um resultado final sempre funcional com virtualmente nenhuma chance de problemas, conflitos ou falhas de dependência. No geral pesando as desvantagens do maior espaco em disco, as vantagens justificam a popularizacão do formato PBI por usuários típicos do PC-BSD.

 

fonte: fug-br  –  Por P. Tracanelli (FreeBSD Brasil)

Hoje venho falar de algo que não é novidade no mundo BSD mas aqui, para nós, não é tão utilizado quanto uma certa distribuição GNU/Linux. FreeBSD sempre foi um sistema voltado para servidores mas nada impedia que fosse instalado em desktops. Como sabemos existem muitos pacotes e configurações necessárias para que o sistema se torne mais amigável. Para esse propósito surgiu um projeto como o PC-BSD. O projeto tem o objetivo de ser usado no ambiente desktop tornando-o mais simples ao usuário. Se gostas de um desafio e conhecer novos ambientes por que não experimentar esse sistema? Um outro projeto destinado à desktops mas de uma forma mais Hacker, é o MidnightBSD. Não sou daqueles que afirmam que um sistema é melhor ou pior que o outro mas incentivo as pessoas à experimentarem e verem se gostam. Isso sim é liberdade, poder usar aquilo que gostamos. Se o que gostamos é pago ou free aí é outro problema. Mas liberdade, para mim, é ser livre para poder escolher. Ser obrigado à algo não é e nunca será sinônimo de liberdade.

Vamos à algumas características de cada Desktop:

PC-BSD: atualmente na versão 9.0, esse projeto é o mesmo FreeBSD e acompanha seu versionamento oficial. Possui todos os recursos existentes no FreeBSD mas também tem umas características únicas, como seu sistema de empacotamento próprio conhecido como PBI (Push Button Installer). Os arquivos .pbi, encontrados no repositório AppCafe™,  facilitam a instalação de novos pacotes e a atualização do sistema como um todo. Uma comparação seria a semelhança com o Central de Programas do Ubuntu Linux. Também pode ser instalado com KDE, Gnome e outros gerenciadores de janelas.

Umas imagens de desktops com PC-BSD:

MidnightBSD: atualmente na versão 0.3. O MidnightBSD tem uma característica bem diferenciada do PC-BSD pois este surgiu de um fork do FreeBSD 6.1 beta mas a versão atual foi baseada no FreeBSD 7.0. Este sistema possui também tecnologia proveniente do DragonFly, OpenBSD e NetBSD. A instalação não é amigável como a do PC-BSD. Eu vejo o MidnightBSD para um público desktop Hacker vamos dizer assim.  🙂

Eles criaram um sistema de gerenciamento de pacotes chamado mports com o intuito de facilitar a nossa vida e muito parecido em sua sintaxe com o apt-get do GNU/Debian. Exemplos: mport update, mport search <string>, mport info <pacote>, mport install <pacote> e outros mais.

 

 

 

 

 

 

 

Bem, agora é com vocês e boa diversão.