Warner Losh, membro do Core Team do FreeBSD lista, em 18 passos simples, como criar um FreeBSD customizado e bootável, demonstrando que ao contrário do que muitos pensam - ou reclamam - criar um FreeBSD do zero, a partir dos fontes, é muito simples. Segue a tradução, a íntegra, do post de Warner em seu blog:

De tempos em tempos ouço pessoas reclamar sobre o quão difícil é criar uma imagem à partir dos fontes do FreeBSD. Essa semana vou explicar como criei uma imagem de i386 bootável em um dispositivo USB, e também fazer observações sobre o resultado.

Recentemente precisei criar uma imagem bootável de i386. A forma mais fácil foi compilar uma nomeu amd64. Configurei meu ambiente para os processos de compilação (passos 1 a 3), construí as aplicações de userland e kernel do FreeBSD (passos 4 e 5), preparei a flash (passos 6 a 11), instalei a userland e o kernel (passos 12 e 13) e adicionei alguns arquivos extras, necessários para o boot (passos 14 a 18). Seguem os comandos abaixo:

1. setenv MAKEOBJDIRPREFIX /blah
2. setenv TARGET i386
3. setenv TARGET_ARCH i386
   
4. make buildworld
5. make buildkernel KERNCONF=GENERIC
   
6. fdisk -I da0
7. fdisk -B da0
8. bsdlabel -w da0s1 auto
9. bsdlabel -B da0s1
10. newfs /dev/da0s1a
11. mount /dev/da0s1a /mnt
12. make installworld DESTDIR=/mnt
13. make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t
    
14. make distrib-dirs DESTDIR=/mnt
15. make distribution DESTDIR=/mnt
16. echo /dev/da0s1a / ufs rw 1 1 > /mnt/etc/fstab
17. echo ifconfig_DEFAULT=DHCP > /mnt/etc/rc.conf
18. echo hostname=demo >> /mnt/etc/rc.conf

Coloquei tudo em um cartão SD e inseri-o em um adaptador USB, iniciando o laptop com ele. A base do FreeBSD não é muito grande hoje em dia, 205MB é suficiente para um sistema completo.

% df /mnt
Filesystem 1024-blocks Used Avail Capacity Mounted on
/dev/da0s1a 484822 205570 240468 46% /mnt

Podemos ainda reduzir, mas considerando uma memória SD de 512MB com custo de 5 dólares, não faz sentido reduzir esse projeto para a memória que pretendi utilizar. Afinal só precisava de algo para fazer a transição de meu laptop de FreeBSD/amd64 para FreeBSD/i386.

Se alguém desejar reduzir a quantidade de espaço usado, existem diversas opções que podem ser usadas para reduzir o tamanho do sistema. Em minha experiência, é melhor construir sem essas opções e depois usar as keywords WITHOUT_XXX na hora de instalar, com installworld, mantendo assim a imagem pequena. É simples reduzir o FreeBSD pelo menos pela metade dessa forma, além do kernel que pode ser reduzido a 5MB na maior parte dos casos.

Você pode ainda usar o nanobsd(8) para automatizar esse processo, como pode também o TinyBSD ser utilizado. No futuro vou citar como costumo construir um FreeBSD com 16MB em média.

O desenvolver clement@ tem feito alguns testes de performance com iozone (benchmarks/iozone), e postado os gráficos resultantes dos testes. Os testes são com UFS2 em RAID com gstripe, com zvol em UFS2 e stripe em Zpool, além de UFS2 assíncrono com geom journal. Essencialmente os testes de clement@ são muito interessantes pois tem setups com UFS2 e diversos módulos Geom, em um ambiente tipicamente FreeBSD, enquanto faz abordagens ZFS dos mesmos setups.

Acompanhe os gráficos publicados nestes testes no blog do desenvolvedor (1 , 2).

Recentemente tivemos na lista principal aqui da FUG uma thread (ainda em andamento) sobre o lançamento do FreeBSD 7.0RELEASE. Particularmente, considero que o lançamento do FreeBSD 7 não está atrasado, ao contrário, houve uma antecipação do processo como um todo, e mencionei minhas considerações sobre porque o 7.0 não está tão próximo assim de ser lançado.

Como citado, o 7.0-RELEASE não deve mesmo sair antes de Dezembro. Agora contudo, não é mais uma opinião, mas sim uma informação discutida publicamente no canal #BSDPorts (rede de IRC efnet), a agenda de lançamento do processo de engenharia de versões será a seguinte:

As datas, como mencionado por ivoras@, podem ainda sofrer pequenas modificações, e não são ainda oficiais. O cronograma oficial será publicado em http://www.freebsd.org/releng/. Mas na prática as modificações, se houver, devem ser com antecipações ou prorrogações de poucos 1 a 2 dias.

O novo escalonador do FreeBSD, disponível no RELENG_7, SCHED_ULE, é, de fato, um novo escalonador, tendo do SCHED_ULE antigo apenas o nome. Esse escalonador tem se mostrado não apenas muito bom, mas plagiando a consideração do Chris DiBona, gerente de projeto Open Source do Google, "SCHED_SMP is a masterpiece", algo como "SCHED_SMP é uma obra-de-arte", se referindo a quando SCHED_ULE era ainda chamado SCHED_SMP no FreeBSD 7.0-CURRENT.

Já divulgamos que os resultados de performance e resposta do FreeBSD com o novo escalonador comparado ao Linux, mesmo com seu novo escalonador - o CFS - ou Solaris, sejam em benchmarks práticos, com aplicações, como em testes de estresse sob grande load. Enfim, referências sobre o quão bom o escalonador se apresenta, ou como ele funciona, ou comparações dos modelos de decisão adotado neste ou em outros escalonadores podem ser observados em diversas referências (1 , 2, 3, 4 , 5 , 6, 7 , 8, 9 , 10 , 11 ...).

Mas o que interessa é, o FreeBSD adotará o SCHED_ULE em sua terceira encarnação, por padrão, a partir do RELENG_7? Sim, mas não a partir do FreeBSD 7.0-RELEASE. O escalonador em questão foi testado exaustivamente, e não apresenta problemas em nenhum ambiente, obtendo melhorias significativas em praticamente todo cenário. E então, porque não torna-lo padrão? Simples, o Projeto FreeBSD nunca foi conhecido por decisões arrojadas na condução de suas tecnologias. Mais que isso, sempre foi bastante conservador nessas decisões. O algorítimo de auto-tunning do maxusers é conservador. Um administrador FreeBSD mais bem preparado faz esse tuning sempre, de forma mais específica. O granularidade do sistema operacional há decadas justifica seu valor em 1000, e por anos, foi 100 (1000 se tornou padrão apenas recentemente), enquanto em arquiteturas 64bits pode ir facilmente para 2000 ou 3000. O que nunca é feito por padrão. Manter o SCHED_4BSD no kernel GENERIC no FreeBSD 7.0-RELEASE é só mais uma dessas decisões conservadores, que historicamente se tornou uma grande característica de condução do FreeBSD.

Isso demonstra a seriedade com que o Projeto aborda a adoção de tecnologia, e principalmente, o quanto requer que o usuário FreeBSD esteja ciente, com bastante antecipação, de modificações drásticas. O SCHED_ULE estará disponível no 7.0-RELEASE em sua melhor forma, mas não no GENERIC. Assim, todos poderemos ao longo do 7.0, trocar de escalonador, como um ítem adicional em nossa checklist.

Quando a árvore RELENG_7 estiver Open, em algum momento, durante o 7.0-STABLE, o SCHED_4BSD será substituído pelo ULE, e o planejamento é que no 7.1-RELEASE este já seja o escalonador no kernel GENERIC. Decisão apropriada, dada a importância de um RELEASE ponto-zero.

O hwpmc(4) existe no FreeBSD desde o início do ramo RELENG_6, e portanto está longe de ser uma novidade no sistema. Mas é pouco conhecido, e normalmente utilizado apenas por desenvolvedores ou administradores de sistema com conhecimento mais avançado, tal qual ktrace por exemplo. O que o hwpmc(4) faz é virtualizar os PMCs (Contadores de Medidas de Performance), recurso disponível praticamente em todos os processadores modernos, que mede informações de baixo nível em eventos de hardware como perda de cache de CPU, perda de TLB e antecipação errônea de ramificação de instruções.

Podendo virtualizar esses contadores, diversos processos podem, simultaneamente, utilizá-los, de forma concorrente. Com isso é possível obter modelos e profiling dessas informações, inclusive em operações em múltiplas CPU. Com isso pode-se rastrear todos os eventos de hardware que aconteçam, e comparar com os eventos que acontecem normalmente e poder identificar por exemplo, atividades incomuns.

Tudo bom, tudo muito bonito, mas qual a novidade? A divisão de código aberto do Google financiou o desenvolvimento de um novo recurso complementar no hwpmc(4) do FreeBSD, e a reimplementação parcial do recurso, que portanto, será no FreeBSD RELENG_7 diferente, internamente, do que temos até agora.

O novo, e a partir de agora principal recurso do hwpmc(4) é que o monitoramente das atividades não é mais passivo. Foi adicionado um recurso que permite a captura de chamadas realizadas pelas aplicações que disparam os eventos físicos na CPU, oferecendo mais informações e melhorando a percepção do comportamento do sistema. Resumidamente, agora é possível saber exatamente em que momento, no código da aplicação, os recursos de CPU são disparados, e fazer o profiling de que chamadas, em que laços do código ou sob que circunstâncias as atividades de CPU (notávelmente as incomuns) tornam-se mais ativas e presentes.

Esses "momentos" no código, são classificados de hot locations. Permitem aos desenvolvedores e administradores avançados de sistema identificar o motivo, com precisão, do consumo de recurso de CPU e principalmente comparar em tabelas de profiling as chamadas e trechos que, ao ser ativados, disparam a maior parte das instruções, oferecendo portanto estatística, complementarmente.

De acordo com Kris Kennaway, desenvolvedor FreeBSD, "hwpmc é uma das nossas ferramentas mais poderosas para medir e entender performance de CPU no FreeBSD. Suportar profiling de chamadas era um recurso importante que nãodispunhamos, e que agora simplifica a habilitado dos desenvolvedores em analizar gargalos de performance no kernel, em código de aplicações de nível de usário, e principalmente de entender seus motivos. Essas adições foram valiosas no ciclo de desenvolvimento do FreeBSD 7."

O desenvolvedor Kip Macy destaca que os novos recursos do hwpmc(4) foram de valor inestimável para o tuning do suporte FreeBSD a ambiente de 10Gbit/s - um dos projetos de destaque na lista da FreeBSD Foundation.

Você pode ler mais sobre as melhorias no hwpmc(4) no FreeBSD, nessa entrada do Google Code Blog, e também no breve relatório da Fundação FreeBSD , além do Wiki do Projeto.

Com o commit abaixo, o RELENG_7 é criado e passa a conter o código que originará o 7.0-RELEASE, a partir desse momento podendo a gerar FreeBSD -BETA e -PRERELEASE mediante sincronia com esse ramo, enquanto o ramo "." (HEAD) desde hoje passa a gerar o 8.0-CURRENT.

As próximas etapas incluem a publicação dos Release Candidates e depois disso, o 7.0-RELEASE.

Subject: cvs commit: src UPDATING src/release Makefile src/sys/conf newvers.sh src/sys/sys param.h src/usr.sbin/pkg_install/add main.c src/share/examples/cvsup stable-supfile
Date: Thu, 11 Oct 2007 04:28:08 +0000 (UTC)
From: Ken Smith
To: Este endereço de e-mail está sendo protegido de spam, você precisa de Javascript habilitado para vê-lo , Este endereço de e-mail está sendo protegido de spam, você precisa de Javascript habilitado para vê-lo , Este endereço de e-mail está sendo protegido de spam, você precisa de Javascript habilitado para vê-lo

kensmith    2007-10-11 04:28:08 UTC

  FreeBSD src repository

  Modified files:
    .                    UPDATING
    release              Makefile
    sys/conf             newvers.sh
    sys/sys              param.h
    usr.sbin/pkg_install/add main.c
    share/examples/cvsup stable-supfile
  Log:
  To honor the birth of RELENG_7 bump HEAD to 8.0-CURRENT.

  Approved by:    re (implicit)

  Revision  Changes    Path
  1.508     +5 -2      src/UPDATING
  1.925     +3 -3      src/release/Makefile
  1.33      +4 -4      src/share/examples/cvsup/stable-supfile
  1.73      +1 -1      src/sys/conf/newvers.sh
  1.309     +1 -1      src/sys/sys/param.h
  1.73      +2 -1      src/usr.sbin/pkg_install/add/main.c

Ao longo de 30 dias, usando PC-BSD como sua plataforma de Desktop principal, diariamente, Jan Stedehouder testou esse sistema, uma versão customizada do FreeBSD focada no ambiente Desktop, que se propõe a ser uma Workstation BSD Unix de fácil uso (e de fato é o BSD voltado para Desktop mais bem sucedido), e chega após um mês, a seu veredito. A conclusão é positiva, considerando a abordagem não técnica do revisor e focando um usuário médio comum, conclui que o PC-BSD tem muitos pontos positivos e também bastante pontos negativos, como era de se esperar, mas que de forma geral em um ambiente Linux voltado a Desktop, costuma ter uma quantidade equivalente de problemas, e mesmo em ambiente Windows também tem quantidade equivalente de problemas, mas a diferença entre Desktop BSD, Desktop Linux ou Desktop Windows é que os problemas - e as soluções - são diferentes, mas presentes na mesma proporção.

Destaca porém a estabilidade geral do ambiente de trabalho com PC-BSD, sobre suas experiências passadas, mas ilustra que a estabilidade e performance, intrísecas as raízes BSD do sistema, ficam menos relevantes se a instalação de um software falha ou o memory stick não é fácil de ser utilizado por um usuário Windows típico, e conclui dizendo que não indica PC-BSD para alguém tentando se afastar do Windows, mas indica fortemente para qualquer pessoa com alguma experiência em sistemas livres, e considera a facilidade de obter informações e simplicidade de abordagem do PC-BSD os grandes pontos fortes, que tende a tornar o projeto mainstream rapidamente.

Considerando que é uma análise, diferente de outras, que não tem como foco comparar PC-BSD com uma opção de Desktop em Linux - estas sempre muito favoráveis ao PC-BSD - mas dessa vez, o PC-BSD para um usuário mais tradicional, tipicamente Windows, as conclusões e análises de Jan Stedehouder ao longo desse mês são muito positivas, e principalmente, pé-no-chão, sem entusiasmo típico de adeptos de sistemas open source, e sem o ceticismo de usuários Windows mais enraizados. Sem dúvida uma das mais completas e paupáveis análises do PC-BSD, cuja conclusão no artigo final (em inglês) pode ser lida aqui, e as análises dia-a-dia, podem ser observadas aqui.