FreeBSD

... oPtimizando o kernel.

O que queres? Um kernel mais leve, mais rápido, menor ou o quê? Em termos de opções de kernel, o FreeBSD é um dos melhores. Não... eu diria que ele é "O MÁXIMO". Mas tudo depende do que se quer fazer com ele. A maneira mais simples é copiar o GENERIC para um arquivo com o nome da tua máquina e começar a pensar no que mexer.

# cd /usr/src/sys/i386/conf
# cp GENERIC MEUKERNEL

Depois de alterado o arquivo MEUKERNEL, a compilação do MEUKERNEL é feita usando-se o parâmetro KERNCONF:

# cd /usr/src
# make buildkernel KERNCONF=MEUKERNEL

e instalar:

# make installkernel KERNCONF=MEUKERNEL


Supondo que saibas toda esta estória de 'make buildkernel', 'make installkernel', 'make buildworld' etc., os comentários deste artigo são mais específicos para a configuração do kernel a ser compilado. Se não sabes, melhor dar uma lida antes em: Building and Installing a Custom Kernel. [1]

Tamanho do Kernel

O tamanho do kernel depende do que ele carrega para a memória em termos de módulos. Hoje o FreeBSD é bem mais modulado mas, mesmo assim, alguns módulos acabam levando muito código inútil para o kernel, aumentando a memória utilizada (memory footprint). Em servidores, por exemplo, pode-se eliminar todos os módulos de rede wireless se eles forem todos cabeados.

# Wireless NIC cards
device          wlan            # 802.11 support
device          wlan_wep        # 802.11 WEP support
device          wlan_ccmp       # 802.11 CCMP support

etc...

Omitir a opção de sistemas de arquivo MSDOS (options  MSDOSFS) aumenta a liberação de memória, bem como eliminar os símbolos de DEBUG (makeoptions  DEBUG=-g). Só isto pode liberar cerca de 60% a 70% da memória utilizada pelo kernel.

Sim, estás pronto para compilar o kernel... mas, espere... "se voce fizer agora voce ainda leva mais uma máquina de lavar..." oops, não! Isto é marketing... nós ainda precisamos de making não de marketing.

O make usa um arquivo /etc/make.conf que, se nunca o editastes, provavelmente, ele não existe ainda. Mas tem um arquivo de configuração no /usr/local/etc/default/make.conf que pode servir de base para criares o teu. Ele serve para as opções do make e pode ser usado para otimizar o compilador para determinado tipo de CPU [2] e escolher opções (flags) de compilação.

Tipo de CPU

Permite o controle do código que é gerado especificamente para uma determinada CPU. Isto pode tornar o Kernel mais rápido e adaptado para teu tipo de arquitetura e pode ser feito usando-se a variável CPUTYPE.

CPUTYPE=<tipo>

Onde <tipo> pode ser uma CPU x86 tipo AMD (opteron, athlon-mp, athlon-xp, athlon-4, athlon-tbird, athlon, k8, k7, k6-3, k6-2 ou k5), tipo Intel (core2, core,nocona, pentium4m, pentium4, prescott, pentium3m, pentium3, pentium-m, pentium-2, pentiumpro, pentium-mmx, pentium, i486 e i386), tipo Via (c3 e c3-2), Alpha/AXP (ev67, ev6, pca56, ev56, ev5, ev45 e ev4), tipo AMD64 (opteron, athlon64, nocona, prescott, core2) e Intel64 (itanium2, itanium).

Flags de compilação:

Existem flags de compilação para a compilação de programas e aplicativos (CFLAGS) e para a compilação do kernel (COPTFALGS). Normalmente pode-se usar nível 3 (-O3) em CFLAGS e nível 2 (-O2) em COPTFLAGS. A compilação do kernel nunca deve ser feita com -O3 porque tende a produzir efeitos colaterais indesejáveis no kernel resultando em kernel panic. Normalmente, o -O3 produz um código mais veloz em detrimento do tamanho do binário gerado.

CFLAGS= -O3 -pipe -funroll-loops -ffast-math
COPTFLAGS= -O2 -pipe -funroll-loops -ffast-math

A opção -pipe permite que a passagem de códigos entre processos se de por pipe ao invés de arquivos temporários. A opção -funroll-loops desdobra os loops de número conhecido de iteratividade, permitindo maior velocidade de execução. Finalmente, a opção -ffast-math elimina as regras estritas de operações matemáticas descritas nas normas IEEE/ANSI. Esta opção deve ser evitada no caso de implementações estritas destas normas como, por exemplo, na compilação do Scilab, Octave ou das bibliotecas ATLAS e BLAS, bem como no desenvolvimento de programas que usem código GSL (Gnu Scientific Library).

Caso não queira alterar as opções do make, pode-se usar o arquivo de configuração do kernel e na linha abaixo da declaração 'machine', adicionar:

makeoptions    COPTFLAGS="-O2 -pipe -funroll-loops -ffast-math"

Outros truques (tricks):

Uma outra maneira de se limitar a memória usada pelo kernel é desabilitar o código relativo ao serviço de NFS. Se tu estás configurando uma estação ou servidor e sabes que não vais usar sistemas de arquivo remotos via NFS, podes usar a opção:

options        NFS_NOSERVER

Outra maneira de diminuir a memória usada pelo kernel é estabelecer o número máximo de dispositivos de swap. Normalmente o kernel precisa alocar uma quantidade fixa de memória para mapear a intercalação dos dispositivos de swap (operação chamada de interleave). Normalmente uso 1 para estações de trabalho e 2 para servidores.

options         NSWAPDEV=<number>

Referências:



[1] Manual do FreeBSD online: http://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html

[2] Kinsella, R. "Profiling and Debugging the FreeBSD* Kernel", Intel White Paper, Document Number: 321772-001, Intel Corp., 2009.

Virtualização

Xen, Qemu, VirtualBox, VMWare... o que usar?

Primeiramente, tudo depende do que o usuário necessita. Por exemplo, se é necessário criar máquinas virtuais para distribuição de serviços (http, smtp, ftp etc.) então o Xen é "o cara". Se for para testar a portabilidade entre diversas arquiteturas (x86, Sparc, PPC etc.) então a opção é o QEMU. Se for para testar performance em diversos SOs ou rodar outras distribuições em mesma arquitetura de processador, então o VirtualBox da Oracle pode ser a melhor opção.

Basicamente, podemos dizer que QEmu + KVM e VirtualBox são equivalentes, enquanto o Xen e VMWare ESXI têm uma outra abordagem de virtualização. O Xen é um virtualizador (hypervisor — a tradução é livre e minha) ou seja, uma camada de software que corre diretamente no hardware do computador, substituindo o sistema operacional propriamente dito.

A virtualização pode ser vista como um sistema "hospedeiro" e um sistema "cliente". O sistema hospedeiro pode disponibilizar recursos de hardware para que um virtualizador controle uma ou mais máquinas virtualizadas (Fig. 1).

Figura 1. Esquema de virtualização do VirtualBox

Os mais importantes virtualizadores de hoje são:


Xen

Usa um modelo denominado "thin hypervisor", com um executável de 2 MB; é atrelado aos service domains; e não usa drivers (os sistemas hospedeiros é que carregam módulos e drivers necessários). Em resumo é uma virtualização real do hardware.

VMware ESXI

Similar ao Xen mas contém os drivers de harware e mantém o gerenciamento de pilhas. O suporte do hardware depende dos drivers do VMware. [1]

QEMU+KVM

É diferente da virtualização do Xen ou do VMware. A virtualização é feita no kernel do sistema hospedeiro. A virtualização do hardware é feita pelo software e o processador virtualizado pode ser de qualquer arquitetura suportada (x86, PPC, ARM, MIPS, Sparc 32 e 64, Motorola M68k etc.) oferecendo maior portabilidade. O KVM é um acelerador da virtualização no kernel que permite a execução do código nativo enquanto emula o restante da máquina. O QEMU pode emular o multiprocessamento simétrico (SMP) mesmo em um hospedeiro com apenas uma CPU. [2]

VirtualBox

Desenvolvido inicialmente pela Sun MicroSystems e agora mantido pela Oracle, o VirtualBox é uma excelente escolha para a virtualização de sistemas operacionais sob uma mesma arquitetura. O modelo de virtualização é de compartilhamento do hardware do hospedeiro, rodando o software do sistema virtualizado direto na CPU. Entretanto o VirtualBox sempre monitora para evitar danos ao sistema hospedeiro. Os processadores Intel e AMD já suportam as tecnologias VT-x e AMD-v para a virtualização de hardware, permitindo ao VirtualBox a interceptação de operações potencialmente danosas.

Nota: em alguns sistemas é necessário habilitar a funcionalidade na BIOS.

VirtualBox [3], Xen [4] e KVM [5] são baseados no QEMU. O QEMU-SystemC [6] usa QEMU para simular um sistema onde os dispositivos de hardware são desenvolvidos em SystemC.

Referências:

[1] http://www.vmware.com/, The VMWare PC virtualizer.

[2] http://wiki.qemu.org/Main_Page, open source processor emulator.

[3] http://virtualbox.org/, The VirtualBox PC virtualizer.

[4] http://www.xen.org/, The Xen hypervisor.

[5] http://kvm.qumranet.com/kvmwiki/Front_Page, Kernel Based Virtual Machine (KVM).

[6] http://www.greensocs.com/projects/QEMUSystemC, QEMU-SystemC, a hardware co-simulator.

Fedora spins

... de assassino da microsoft a futuro da humanidade!

Não sou eu quem diz isto! Isto foi publicado em 1999 pelo Web Developers Journal E este era o "mot" do Caldera OpenLinux 2.2. Por esta época, dois SOs se preparavam se não para matar, pelo menos para incomodar o império de William Gates III. Eram eles: o Caldera OpenLinux e o RedHat. Às vésperas (sic) do novo Windows da Microsoft ( o tal de 8) que tem uma interface denominada "metro" lembrei-me da história. Curiosamente, o Caldera vinha com uma interface gráfica proprietária chamada "metro" baseada no MetroLink's Motif e no  Accelerated-X da Xi Graphics. Será esta a vingança "saramaligrina" do império? Argh!

O Caldera desapareceu depois da junção com a SCO e a briga judicial delas com a IBM... mas isto é outra estória da história [1]. A função acabou sobrando para a RedHat que logo entendeu que, se quisesse desbancar o "império",  precisava se firmar no mercado para desempenhar este papel. O SO da RedHat acabou se dividindo entre uma parte comercial e proprietária e uma parte subsidiada e patrocinada pela RH chamado de "Fedora".

Dentre as distribuições de Linux, o Fedora [2] sempre se impôs e vem mantendo a fama de uma distro confiável, estável e robusta, voltada para desktops. Usando um sistema de instalação e atualização baseada no RPM (RedHat Package Manager) é um sistema altamente configurável para a atividade de cada tipo de usuário. Hoje o Fedora pode ser instalado com Gnome 3 (Gnome-shell), KDE 4 (plasma) e, ainda, LXDE ou XFCE.

Mas o usuário já pode se despreocupar de ficar reconfigurando a cada reinstalação ou atualização de seu desktop. O Fedora lançou a idéia dos "Spins" (no sentido de torneado, adaptado, feito sob medida) [3].

Segundo a própria RH,

"As Spins do Fedora são versões alternativas do Fedora, adaptadas para vários tipos de usuários com coleções de aplicativos selecionados ou customizações." 

E tem mais... todos no formato de instalação ou "live" (tanto em CD como em pendrive com boot).

Algumas destas distros Fedora Spin contemplam as áreas de computação científica, robótica, design gráfico, games, administração de redes e segurança etc.; e ainda distros com ambientes gráficos específicos (KDE, LXDE, XFCE etc.).

Com o preço dos pendrives tão baixo alguém pode até dar-se o luxo de ter várias distros específicas para rodar no seu box, além claro de poder usá-las em virtualizações.

seja feliz, free, fedora ... be the force with you, Luke!

Referências:

[1] Wikipedia, "SCO vs IBM", http://en.wikipedia.org/wiki/SCO_v._IBM (acesso em 28/11/2011)

[2] Fedora: visão geral https://fedoraproject.org/wiki/Overview/pt-br (acesso em 28/11/2011)

[3] Fedora Spins: http://spins.fedoraproject.org/ (acesso em 28/11/2011)

SO - Semáforos

... e ninguém desrespeita!

Os sistemas operacionais tipo Unix têm uma característica interessante; neles, tudo é tratado como um arquivo. Por exemplo: existem arquivos comuns, diretórios, links para arquivos e até mesmo um dispositivo é um arquivo. A saída (terminal/monitor), o teclado, uma unidade de disco ou uma porta de rede são todos tratados como arquivos pelo SO.

O Unix é tipicamente um SO multiusuário e, não raro, o sistema deve permitir o acesso a um arquivo por um aplicativo e, frequentemente, acontece de mais de um processo precisar acessar um arquivo.

Nos Unices, semáforo (semaphore) é a designação de uma variável que funciona como um contador que controla o acesso aos recursos (arquivos) pelos processos dos usuários. Ou seja, se um processo está acessando um arquivo o semáforo é iniciado e, se outro tenta acessar o mesmo arquivo ele verifica o estado do semáforo e o encontra iniciado, tendo que esperar "o sinal abrir".  Quando o primeiro processo termina o acesso ao arquivo o semáforo é reiniciado e o outro processo pode acessar o arquivo pois "o sinal está aberto". Para o usuário, todo o processo é transparente e controlado pelo núcleo (kernel) do SO.

No caso de mais de um processo — que é o que ocorre mais comumente — o semáforo serve para coordenar a fila de processos que vai usar determinado recurso. Cada semáforo tem uma identidade e deve ser armazenado no kernel para poder ser acessível a todos os processos.

Um semáforo pode ser criado pela função em C "int semget(key_t, int, int)" que recebe três argumentos e retorna um int que é o identificador do semáforo.

#include <sys/types.h>     #include <sys/ipc.h>     #include <sys/sem.h>     int semget(key_t key, int nsems, int flag);

Com base nos valores de "key" e "flag" a função retorna o identificador do semáforo criado ou -1 no caso de ocorrer um erro e não se possa criar o semáforo.

O comando 'ipcs -s' no Unix reporta os semáforos existentes. Para cada semáforo criado é criada uma estrutura no kernel do SO com o nome de 'semid_ds' prototipada em <sys/ipc.h> e em <sys/sem.h>.

As funções abaixo são de semáforos (veja "man <num> <func>" para mais detalhes).


ipcrm (1)            - remove uma fila de mensagens, conjunto de semáforos ou memória compartilhada
sem (4)              - POSIX semaphores (BSD)
sem_close (3)        - fecha um determinado semáforo
sem_destroy (3)      - destrói um semáforo qualquer
sem_getvalue (3)     - obtém o valor de um semáforo
sem_init (3)         - inicia um semáforo qualquer
sem_open (3)         - inicia e abre um determinado semáforo
sem_overview (7)     - POSIX semaphores (Linux)
sem_post (3)         - destrava um semáforo (incrementa)
sem_timedwait (3)    - trava um semáforo (BSD/Linux)
sem_trywait (3)      - trava um semáforo (decrementa)
sem_unlink (3)       - remove um determinado semáforo
sem_wait (3)         - trava um semáforo (decrementa)
semctl (2)           - controle de operações de semáforo
semget (2)           - obtém um identificador para semáforo
semop (2)            - Operações de semáforos
semtimedop (2)       - Operações de semáforos

Referências:


Dunstan, N. e Fris, "Process Scheduling and UNIX Semaphores", in: I.Software—Practice and Experience, Vol. 25(10), 1141–1153 (October, 1995).

Callari F. "Synopsis on Concurrency", http://www.cim.mcgill.ca/~franco/OpSys-304-427/lecture-notes/node29.html (acesso em 25/11/2011)

Apêndice (exemplo):

Os códigos abaixo (de Unix Systems Programming - Examples) demonstram a utilização de semáforos.

semabinit.c:

/* semabinit.c - initialize a semaphore for use by programs sema and semb */

#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include <stdio.h>

/* The semaphore key is an arbitrary long integer which serves as an
   external identifier by which the semaphore is known to any program
   that wishes to use it. */

#define KEY (1492)

void main()
{
   int id; /* Number by which the semaphore is known within a program */

   /* The next thing is an argument to the semctl() function. Semctl() 
      does various things to the semaphore depending on which arguments
      are passed. We will use it to make sure that the value of the 
      semaphore is initially 0. */

 union semun {
  int val;
  struct semid_ds *buf;
  ushort * array;
 } argument;

   argument.val = 0;

   /* Create the semaphore with external key KEY if it doesn't already 
      exists. Give permissions to the world. */

   id = semget(KEY, 1, 0666 | IPC_CREAT);

   /* Always check system returns. */

   if(id < 0)
   {
      fprintf(stderr, "Unable to obtain semaphore.\n");
      exit(0);
   }

   /* What we actually get is an array of semaphores. The second 
      argument to semget() was the array dimension - in our case
      1. */

   /* Set the value of the number 0 semaphore in semaphore array
      # id to the value 0. */

   if( semctl(id, 0, SETVAL, argument) < 0)
   {
      fprintf( stderr, "Cannot set semaphore value.\n");
   }
   else
   {
      fprintf(stderr, "Semaphore %d initialized.\n", KEY);
   }
} 

sema.c:

/* Semaphore example program a (sema.c) */
/* We have two programs, sema and semb. Semb may be initiated at any 
  time, but will be forced to wait until sema is executed. Sema and
  semb do not have to be executed by the same user! */

#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>

#define KEY (1492)
/* This is the external name by which the semaphore is known to any
   program that wishes to access it. */

void main()
{
   int id;  /* Internal identifier of the semaphore. */
   struct sembuf operations[1];
   /* An "array" of one operation to perform on the semaphore. */

   int retval; /* Return value from semop() */

   /* Get the index for the semaphore with external name KEY. */
   id = semget(KEY, 1, 0666);
   if(id < 0)
   /* Semaphore does not exist. */
   {
      fprintf(stderr, "Program sema cannot find semaphore, exiting.\n");
      exit(0);
   }

   /* Do a semaphore V-operation. */
   printf("Program sema about to do a V-operation. \n");

   /* Set up the sembuf structure. */
   /* Which semaphore in the semaphore array : */
    operations[0].sem_num = 0;
    /* Which operation? Add 1 to semaphore value : */
    operations[0].sem_op = 1;
    /* Set the flag so we will wait : */   
    operations[0].sem_flg = 0;

    /* So do the operation! */
    retval = semop(id, operations, 1);

    if(retval == 0)
    {
       printf("Successful V-operation by program sema.\n");
    }
    else
    {
       printf("sema: V-operation did not succeed.\n");
 perror("REASON");
    }
}

/* Think carefully about what the V-operation does. If sema is executed 
   twice, then semb can execute twice. */ 

semb.c:

/* Semaphore example program b (semb.c) */
/* We have two programs, sema and semb. Semb may be initiated at any 
  time, but will be forced to wait until sema is executed. Sema and
  semb do not have to be executed by the same user! */

/* HOW TO TEST:
   Execute semb &
   The & is important - otherwise you would have have to move to
   a different terminal to execute sema.

   Then execute sema.
*/

#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>

#define KEY (1492)
/* This is the external name by which the semaphore is known to any
   program that wishes to access it. */

void main()
{
   int id;  /* Internal identifier of the semaphore. */
   struct sembuf operations[1];
   /* An "array" of one operation to perform on the semaphore. */

   int retval; /* Return value from semop() */

   /* Get the index for the semaphore with external name KEY. */
   id = semget(KEY, 1, 0666);
   if(id < 0)
   /* Semaphore does not exist. */
   {
      fprintf(stderr, "Program semb cannot find semaphore, exiting.\n");
      exit(0);
   }

   /* Do a semaphore P-operation. */
   printf("Program semb about to do a P-operation. \n");
   printf("Process id is %d\n", getpid());

   /* Set up the sembuf structure. */
   /* Which semaphore in the semaphore array : */
    operations[0].sem_num = 0;
    /* Which operation? Subtract 1 from semaphore value : */
    operations[0].sem_op = -1;
    /* Set the flag so we will wait : */   
    operations[0].sem_flg = 0;

    /* So do the operation! */
    retval = semop(id, operations, 1);

    if(retval == 0)
    {
       printf("Successful P-operation by program semb.\n");
       printf("Process id is %d\n", getpid());
    }
    else
    {
       printf("semb: P-operation did not succeed.\n");
    }
}

/* Think carefully about what the V-operation does. If sema is executed 
   twice, then semb can execute twice. */

Unix

Sistemas multitarefa e preemptividade

Frequentemente, alunos de computação ou de sistemas manifestam certas dúvidas com relação à multitarefa e preemptividade. Por isso, resolvi postar aqui no blog sobre este assunto.

Sistemas Unix^TM são sistemas multitarefa, ou seja, executam mais de uma tarefa simultaneamente. Executar mais de uma tarefa em um mesmo processador pode parecer milagre mas é o que parece ao usuário quando as tarefas são executadas em pequenos lotes controlados pelo kernel do sistema operacional (SO). Normalmente, podemos ter dois tipos de multiprocessamento: o colaborativo e o preemptivo.

O processo colaborativo é um processo que emula o multiprocessamento. Ele acontece quando um aplicativo gerencia os processos fazendo a paginação de memória para interromper um deles e rodar o outro. Neste caso, se algum processo bloqueia o aplicativo todos os outros processos tem que ser terminados pois ficam interdependentes, ou seja: tela azul!

O modelo de multiprocessamento preemptivo é um pouco mais elaborado. O kernel do SO estabelece um "quantum" de tempo para cada processo dentro do processador. Enquanto isso, o kernel mantém um registro de todos os processos na memória com uma hierarquia de dependência de cada segmento (thread).

O comando 'ps' do Unix mostra isto:

... 2438 ?     SN  0:08 /usr/bin/nepomukservicestub nepomukontologyloader 2458 ?     Sl  3:16 /usr/lib/firefox-8.0/firefox 2488 ?     S   0:00 /usr/lib/mozilla/kmozillahelper 2497 ?     Sl  0:39 /usr/lib/firefox-8.0/plugin-container /usr/lib/adobe- 2526 ?     Rl  0:01 /usr/bin/konsole 2528 pts/1 Ss  0:00 /bin/bash 2617 pts/1 Sl+ 0:24 gedit blog.txt 2620 ?     S   0:00 /usr/lib/gvfs/gvfs-gdu-volume-monitor 2622 ?     Sl  0:00 /usr/lib/udisks/udisks-daemon 2623 ?     S   0:00 udisks-daemon: polling /dev/sdb /dev/sr0 2625 ?     Sl  0:00 /usr/lib/gvfs/gvfs-afc-volume-monitor 2628 ?     S   0:00 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor 2703 pts/2 Ss  0:00 /bin/bash 2762 pts/2 R+  0:00 ps -ax

Nos SO tipo Unix, pode-se perceber dois tipos de tarefas. O processo "pai" e os processos "filhos" ou segmentos associados ao processo principal (normalmente chamadas de threads do processo). Existe um bloco de endereçamento de memória para cada processo e este é compartilhado pelas threads. No entanto, cada thread tem sua própria pilha (stack) e seu estado de processador.

Em tempo de execução, o kernel usa a prioridade de cada processo para estabelecer o tempo de CPU para cada um. Esta prioridade, chamada de "nice", é típica de cada processo ou estabelecida pelo usuário ou super-usuário. Terminado o tempo de CPU o kernel suspende a execução do processo, salva o seu contexto, fazendo uma paginação da memória que salva as informações necessárias para ele retornar à execução no próximo tempo de CPU. Então, o kernel coloca em execução o próximo da fila de prioridades para ser processado. Quando a fila acaba, o kernel volta a dar o controle da CPU a primeiro da fila, terminando o ciclo.

Mais sobre sistemas Unix: http://www.bell-labs.com/history/unix/

Ubuntu

Vem cá meu lindo... não precisa chorar!

Como sempre, minha implicância com as distribuições Linux duram apenas alguns dias (veja meu post anterior sobre o Ubuntu). Claro que foi bom para testar outras distros e SOs — até mesmo me animou para escrever um pouco sobre isto. Entretanto, eu não resisto a testar coisas novas. Sim, sou volúvel, mesmo! Mas eu não podia aceitar uma distribuição que precisa de aplicativos para se poder configurar um ambiente. Que que é? Parece windows da microsoft!

Mas calma, nem tudo está perdido. É possível rodar o Gnome no Ubuntu 11.10 ou, pelo menos o Gnome 3. Acontece que o Unity roda sobre o Gnome 3 mas com extensões próprias. Até aí nada demais, mas para quem está acostumado com o ambiente em escala maior e usa um desktop com tela de 32 polegadas não se contenta com um Unity. Quer configurar cores, fontes, telas, e todos os adereços de "camarim-de-vedete" que se tem direito. É aí que o Unity falha. Mas afinal, ele é apenas um "skin" do Gnome 3.

Então, se você não gostou do Unity e quer o Gnome de volta... prepare-se!

O Ubuntu 11.10 com Gnome 3

Voce pode instalar o Gnome 3 via gerenciador de programas (veja em http://www.vivaolinux.com.br/artigo/Gnome-Shell-e-Extensions-no-Ubuntu-1110/?pagina=1) ou se preferir, via terminal. Vamos lá:

1. Abra um terminal e digite:

sudo apt-get install gnome-shell

Passe a senha solicitada e deixe o gnome-shell ser instalado. Isto instalará os temas, menus, gconf etc..

2. Encerre a sessão do Unity e retorne para a tela de login.

3. Na tela de login, clique com o lado esquerdo do mouse sobre a engrenagem ao lado do nome do usuário. Selecione o 'Gnome' e faça o login.

Ei-lo! Este é o gnome-shell do Gnome 3.

Até mais limpo que o próprio Unity, não acha?

Sim, voce pode instalar extensões do gnome  aquelas que costumo chamar de "camarim-de-vedete" (para não dizer outra coisa) — via synaptic — e usar o gerenciador de configurações avançadas para habilitá-las. Veja, por exemplo, no forum do Ubuntued: o artigo http://forum.ubuntued.info/viewtopic.php?f=24&p=4313#p4313.

Escolha o Gnome clássico no login para obter a antiga aparência do Ubuntu de volta. O restante é só continuar usando o Ubuntu 11.10 como se fosse um 10.11. :)


E viva feliz com o Ubuntu... que seja eterno enquanto dure.

(fonte da imagem acima: Gnome 3. )

FreeNAS

... ou como computar nas nuvens!

Computação em nuvem é a atual febre. Agora a nuvem da internet assumiu seu formato definitivo... definitivo? Bem, pelo menos por ora. Por isso, escolhi o FreeNAS^TM [1] como tópico deste post.

O FreeNAS^TM é uma plataforma de storage aberta e gratuita. #ProntoFalei... e falei tudo. Somente isto é o suficiente para interessar a qualquer um que pretenda criar um repositório ou um serviço na nuvem. Mesmo que seja o próprio servidor de downloads ou um mediabox local.

O sistema é baseado no FreeBSD e tem suporte a sistemas de arquivos de várias plataformas, indo desde o Mac ao MSWindows e, ainda, o mais importante sobre ZFS (ver meu post sobre ZFS).

Agora vem o mais interessante. Tudo gerenciado via browser. Sim, uma interface web é utilizada para gerenciar o "FreeNAS box". Por meio dela, se pode ligar/desligar serviços, criar e agregar partições, gerenciar discos, criar/gerenciar máquinas virtuais e todo o tipo de administração que um servidor deste tipo necessita.

Requisitos de Hardware.

O FreeNAS 8.0.1 está disponível para arquiteturas 32 ou 64 bits. Como é baseado no FreeBSD 8.2 requer o mesmo tipo de hardware (http://www.freebsd.org/releases/8.2R/hardware.html). Entretanto, especificar o hardware para o FreeNAS^TM vai depender dos serviços que serão disponibilizados no box e o tipo de sistema de arquivos escolhidos. Por exemplo, menos de 6 GB de RAM é melhor usar UFS, pois o ZFS requer, no mínimo 6 GB. Além disso, existe uma relação para sistemas com mais de 6 TB de capacidade de disco. Para cada TB acima de 6 TB é necessário mais 1 GB de memória.

Mas nem tudo é tão gigantesco assim... Se pode instalar um sistema mais restrito com menos RAM e usar o UFS, sem problemas. Principalmente se a proposta for um servidor de mídias local.

Quanto a discos, o FreeNAS^TM suporta sistemas hot swap, Raid 0,1,5,6,10,60 além de Raid Z1 a Z3. (Veja os detalhes no manual)

Algumas facilidades interessantes do FreeNAS^TM:

1. suporte a AFP, CIFS, FTP, NFS, SSH, SFTP, e TFTP
2. suporte a exportação de arquivos e devices via iSCSI
3. suporte a UFS2 com gmirror, gstripe e graid3 e suporte a ZFS
4. suporte a LDAP para autenticação
5. notificação por email sobre controle de eventos LSI RAIS
6. configurações via interface gráfica (WEB)
7. especificação de múltiplos IPs por porta iSCSI
8. compatibilidade com Windows (samba) e OSX 10.7 (netatalk)

Nota: Conforme comentário, as opções de torrent e streaming de áudio e vídeo ainda não se encontram disponíveis para a versão 8.0.2 do FreeNAS. Para usar Bit Torrent, UPnP, iTunes/DAAP use o FreeNAS antigo. A equipe de desenvolvimento promete ainda implementar estas facilidades no FreeNAS 8.1 veja em: http://www.freenas.org/about/news/item/freenas-81-roadmap. No x.7 é fácil configurar. Vá em Serviços->UPnP e clique em habilitar (enable). Veja mais detalhes em http://www.homesystemintegration.com/2011/01/freenas-tutorial-part-4-upnp-streaming/.



Capturas de tela:

Tela de login:

Tela principal:

Tela de relatórios:

Configuração de Snapshot:

Processos (top):

Serviços:

[1] http://www.freenas.org/

HURD

Não, não se trata do Hurd da HP (aquele do escândalo sexual que está agora na Oracle), trata-se sim do mais antigo projeto de sistema free-Unix existente. O unix da própria GNU, o GNU-Hurd.

"Starting this Thanksgiving I am going to write a complete Unix-compatible software system called GNU (for Gnu's Not Unix), and give it away free to everyone who can use it."

Richard Stallman 

(http://www.gnu.org/gnu/initial-announcement.html)

Assim começava o email de Richard Stallman que anunciava, no dia 23 de setembro de 1983, o início de um projeto de criação de um sistema operacional do tipo Unix para ser distribuído e utilizado livremente, sem custo para o usuário. A proposta era criar um kernel com aplicativos para escrever e compilar programas em C, ou seja, um shell com editor, compilador e outros aplicativos típicos de um sistema Unix.

Quase 30 anos depois e me sinto instalando um minix... como pode? Começa que, para instalar do CD deve-se escolher a opção hd2 (qemu). Por que? Não bastava hd2? Afinal quero usar o VirtualBox. Depois dos testes de hardware aparece um prompt:

To login, enter 'login root'.                                                                                                                                                         Use 'login USER' to login, or 'help' for more information    login> _

A primeira letra não aparece... o terminal come: 'ogin root' ... WTF! Tente de novo...

Aí o sistema pergunta se quer usar o 'install' ou o 'install2'... já imaginei, lá vem o Reboot para carregar partições... dito e feito! O 'install' é apenas para particionar o disco e preparar a instalação o kernel é monolítico e não usa a nova partição e precisa de ser recarregado. Então... reboooot! O 'install2' é a etapa de instalação depois do clássico "Reboot"... Ah Stallman, tenha dó!

Disco particionado e partição de swap criada, lá se vai o install2. Nada... parada no "validating packages..." e deu! Tentando RTFM (reading the fucking manual), mas onde está o FM? Finalmente, depois de muito esforço consegui sem ler o FM e, inexplicavelmente, a instalação passou. Isto depois de quase 3 horas de tentativas! Acho muito esforço para instalar um sistema operacional que é prometido há quase 30 anos e ainda acha que tem que ser instalado como os antigos minix, linux (slackware) ou os velhos BSDs.

Mas é para nerd mesmo, pensei, pelo menos vamos testar. Bem, nada de excepcional ou de entusiasmante... Mas vamos lá!

O microkernel 'Mach' é monolítico e inclui as funcionalidades padrão de um sistema tipo Unix mas com os serviços controlados por "objetos". Um "objeto" para o Hurd é uma interface que consiste de um programa e o estado deste programa. As principais são as interfaces fs, fsys, auth, password, exec e proc. Um sistema Hurd é composto, minimamente, pelo kernel 'Mach', um servidor de autenticação (auth), um servidor de processos (proc), um servidor de aplicativos (exec) e um servidor de senhas (password).

A interface mais interessante do Hurd é a fsys que permite a tradução de nomes ('name spaces') que pode ser referenciada dentro do próprio sistema (via mount point). Por exemplo:

$ settrans -a /home/fulano/mnt /hurd/ftpfs  \        fulano:passwd@site.org/~

Este comando cria uma instância do programa ftpfs e ligando o diretório remoto com o nó ~/mnt. Até aí nada demais... KDE e GNOME já utilizam o ftpfs de forma semelhante e de forma transparente para o usuário. Tudo bem que não é o mesmo princípio mas o resultado é o mesmo entretanto mais seguro!

Aplicativos partem do princípio da integridade de um sistema de arquivos e em um Unix normal isto faz sentido posto que todo o sistema de arquivos é parte de um processo confiável. No Hurd, onde programas podem vincular e ampliar o sistema de arquivos a coisa é outra... e bem vulnerável a ataques.

Do ponto de vista da virtualização, o Hurd ainda tem muitas limitações e, neste ponto, o 'FreeNAS' oferece muito mais por muito menos esforço e mais... gerenciável via web (com https, inclusive).

No frigir dos ovos, meu caro Stallman... o Hurd não me entusiasmou em nenhum aspecto. Mesmo esperando algo dele há quase 30 anos. Afinal, certo estava o Torvalds de pegar o sistema do Tanenbaum e fazer o que fez...

Para mais sobre o Hurd: http://walfield.org/papers/200707-walfield-critique-of-the-GNU-Hurd.pdf

ZFS (FreeBSD, Linux e Solaris)

O ZFS (Zettabyte File System) é o sistema de arquivos (file system ou FS) do futuro. Por que? Segurança dos dados, persistência, consistência e integração nativa com os novos processadores.

Sistemas de arquivos representam o "nó górdio" de um sistema operacional (SO). Normalmente, o usuário sabe pouco e espera muito de um sistema de arquivos. Os dados de sistemas operacionais, dados de aplicativos e dados do usuário ficam gravados aí e, exatamente aí, reside o problema. Dados podem se corromper facilmente e mantê-los seguros é o propósito de um FS confiável.

O ZFS foi desenvolvido pela Sun Microsystems e foi implementado, pela primeira vez no Solaris 10. Ele foi desenvolvido com código aberto sob licença CDDL (Common Development and Distribution License) para ser implementado no projeto do OpenSolaris. Uma vez que a Oracle comprou a Sun, o projeto OpenSolaris não mais existe. Mas isto não impede que o projeto do FreeBSD continue a desenvolver sobre o código do ZFS, pois é compatível com a licença BSD. O mesmo não ocorre com a licença GNU (veja no final deste artigo).

A Oracle continua a usar o ZFS no novo sistema (Solaris 11) que vem sendo distribuído livremente, mas não se sabe se estão sendo feitas alterações no código do ZFS ou no Kernel do novo Solaris.

As vantagens do ZFS sobre os outros FS tais como o UFS, ext2, ext3, Reiser, QNX, etc. é a facilidade com que este FS lida com problemas que para os outros sistemas são críticos. Note que aqui cito sistemas de arquivos decentes e deixo de lado os da Microsoft® que são uma "barbárie escatológica" que nem vale a pena comparar, já que "tela azul" é coisa natural para eles.

Além disso o ZFS apresenta a facilidade de manutenção e administração e, o melhor, a integração nativa com a criptografia dos processadores i5 e i7. Assim, para quem precisa rodar o sistema criptografado isto é uma vantagem imensa na performace de disco.

Outra funcionalidade muito interessante é a maneira como o sistema de arquivo lida com os blocos danificados (bad blocks). Em um sistema normal, no espelhamento de dados (Virtual Disk Mirrors), se o sistema físico de um deles tem um bloco de dados defeituoso, o espelho não tem como saber e o valor lido é passado para o FS que pode emitir um sinal de falha (panic) ou, caso contrário passará um dado corrompido e errado para o aplicativo.

No caso do ZFS um checksum revela que um bloco está danificado e, então, o ZFS verifica o checksum do espelho. Se o dado está bom ele é passado para o aplicativo e usado para corrigir o bloco ruim do outro disco.

Querem mais? Pois bem, como cita Dawidek [1]:

• Nunca mais volumes e partições! É isso aí... lida com o armazenamento em disco do mesmo modo que a memória virtual faz com a memória.  
• Usa o modelo "copy-on-write" ou cópia simultânea com a escrita
• Nunca mais fsck ou journaling porque os dados estão sempre consistentes no disco.
• Compressão e criptografia nativa
• Independente de endianness, sempre lida com endianness nativa

O pessoal do Kernel do Linux também está desenvolvendo e portando o ZFS com o nome de FUSE, não considerado como parte do kernel Linux. (veja em: http://zfsonlinux.org/faq.html)

O ZFS, no entanto, passa a ser um sistema desejável para aplicações críticas, principalmente para data centers provedores de conteúdo, armazenamento e bancos de dados.

[1] Dawidek, P. J. "Porting the ZFS file system to the FreeBSD operating system" White Paper, FreeBSD Foundation, http://wiki.freebsd.org/ZFS, acesso em 8/11/2011

 Solaris 11 da Oracle

"If your choice is virtualization and cloud computing you must install Oracle's Solaris 11"

É verdade. Mas daí a ter tudo rodando na ponta dos dedos, vai uma légua de caminhada. Mas nada é tão complicado. Primeiro, a instalação é bem fácil e para ser mais rápido para baixar e instalar, o Solaris 11 Text Install (Express) pode ser uma boa.

Como tudo nesta vida tem seus truques, aqui vão algumas dicas e idéias pois poucos conhecem o SunOS/Solaris. Podemos começar com a instalação. São, basicamente 2 tipos de plataformas: para Sparc e para x86. Quanto a isso, depende do hardware onde o Solaris vai rodar, por exemplo, nas sparcs a lista é grande e quase todas suportam o Solaris (Sparc I, II, IIe, ultraspac III, IIIi, III+ etc.). Assim, é só escolher o arquivo correto de imagem de instalação.

Testei dois tipos de instalação: o primeiro na SunBlade 20'02 que é uma UltraSparc III+; e o segundo em uma máquina virtual (VirtualBox) em plataforma x86. Não há diferença na instalação, apenas o passo 2 para a instalação na UltraSparc é que difere pois o boot pelo cdrom tem que ser especificado no post da máquina. No x86 se configura o boot na BIOS ou por interrupção (esc/função).

Instalação na UltraSparc III+

Passo 1: Ligar e inserir o DVD.

Passo 2: No início do "post" apertar "stop+A" num teclado Sun (em um teclado convencional use "ctrl-A-Break") que aparecerá o sinal de prompt do post:


      Ok? _                                


digite, então, "boot cdrom" para dar o boot no sistema:

      Ok? boot cdrom                       
 
Passo 3: Faça as escolhas de linguagem, teclado, partição (ou disco) e preceda a instalação que não requer muita intervenção. É praticamente automática.

Passo 4: Remova a mídia de instalação e reboot.

A primeira decepção: Modo TEXTO ??!?!? o.O

Sim, modo texto. Esta instalação "express" é modo texto e não instala os componentes gráficos. No início tentei acessar como "root":

WTF!!! o root não loga? O.O !!!

Tudo bem, é uma questão de segurança. É só logar com o usuário criado na instalação e fazer um "su" para root... Beleza:

Instalei o X, o gdm, habilitei o gdm e ... nada! Pois bem, vasculhando na net descobri uma referência de como fazer para o gdm ficar como login default e repasso aqui para os que quiserem se aventurar neste mundo futuro.

Fonte: https://blogs.oracle.com/stw/entry/getting_gdm_to_work_on

Passo 5: Instale o slim_install como root, ou seja,

      fulano@solaris># pkg install slim_install   

Serão instalados quase 400 pacotes (X, gnome, gdm e todas as dependências e softwares básicos).

Passo 6: Defina o GDM como default e reboot.

      fulano@solaris># svcadm enable gdm         

      fulano@solaris># reboot                    

Aí, então, espere para ficar de queixo caído!


Passo 7: login, abra um terminal e exclua o pacote "slim_install".

      fulano@solaris># pkg uninstall slim_install  

Vai desinstalar apenas um pacote (o slim_install).

Voilá... está pronto para começar a explorar o novo solaris e configurar o necessário, principalmente para cloud computing. Não será difícil achar o caminho para instalar e remover software e administrar o sistema e sistemas hospedeiros. Bom trabalho!

Instalação em uma plataforma x86

O processo é o mesmo. No meu caso criei uma máquina virtual em um HP pavillion, instalei usando o mesmo procedimento da Sparc (passo 3 a passo 7).

Algumas imagens para passar mel na boca dos leitores:

O rei morreu... viva o rei!

A mudança radical do Ubuntu foi excelente para mim. Um tipo de "move-your-ass" muito necessário já que me encontrava devidamente resolvido quanto ao problema dos sistemas operacionais a utilizar. Para mim, tudo estava bem delineado: Ubuntu para desktops e FreeBSD para servidores. Ledo engano!

A versão 11.10 do Ubuntu já deu sinais de que vão priorizar o ambiente de tablets... e estão corretos, pois o "touch screen" é a tendência. No entanto, o Unity tem uma interface muito menos intuitiva para desktop, o que faz sentido. Afinal, até o Windows 8.0 virá com uma interface voltada para o mundo tablet --- por sinal, nada criativa nem intuitiva, parecendo mais uma colcha de retalhos de imagens e "quadrados"... valhame, que coisa feia!

A tendência criada pelos "i-phodas" deve se expandir --- ponto para a Apple --- mas não podemos esquecer que os PCs com seus teclados e mouses, pelo menos como máquinas de escrever, continuarão a existir. E aí, estas interfaces não são lá muito ergonômicas. O próprio Windows (XP, Vista e 7) nunca foram muito ergonômicos e perderam para os MacOS neste aspecto. Mas daí a criar uma interface tablet (Windows 8) horrorosa chamada Metro (e que não pode ser desativada) foi a "pá-de-cal". Aliás a Red Hat lançou nos idos de 90 uma interface com o nome de Metro-X. Hei... povo da Microsoft, foi falta de criatividade mesmo ou compraram da RH? Apesar de estarem falando que é cópia do Unity... nem pensar, o Unity é muito mais intuitivo (para tablet, claro!)

Mas voltando ao assunto Linux/BSD, a minha relação com Linux, que começou nos idos de 1992 (alô HBL... onde estás?), foi de amor e ódio. Não era fácil instalar mas depois de configurado era o paraíso para quem tinha que se virar com um PC 386. Descortinava-se todo o universo do software livre e, para quem fazia pesquisa, ter um compilador C como o da GNU e outros softwares disponíveis, além do poderoso shell tipo Unix, era bom demais.

Nestas andanças pelo universo dos sistemas operacionais o FreeBSD acabou me conquistando pelo fato de ser um Unix de verdade e ainda ter um sistema de instalação de pacotes de software como o ports. Novamente, a experiência com o Linux contou muito para que se pudesse instalar e configurar o BSD. Windows? Nunca mais... deixo-o para os tolos que aceitam aquela tela azul como se fosse a coisa mais natural do mundo e idiotas que aceitam a idéia de "ser beta-tester da Microsoft" como conclamou seu dono Bill.

Agora, novamente, enfrento as mudanças... OMG! Mas de forma positiva e descubro que o universo de sistemas operacionais se expandiu! Nos últimos 30 dias experimentei vários deles. Arch, Mint, Suse e o próprio Debian além do Ubuntu (reconfigurado para o Gnome-shell + GTK3... eu diria Gnome-Show) dos principais sabores de Linuxes. Nesta última semana foi a vez do FreeBSD e a grata surpresa de encontrar o PC-BSD (um freeBSD com instalação gráfica e fácil) um "must try" para quem quer liberdade e robustez.

Finalmente, quinta-feira foi a vez do Solaris 11 da Oracle. A instalação no modo texto (do Express) leva a um prompt de terminal onde o root não faz login... tudo bem, "user -> su -> #" :)) Mas cadê o X? nada??? Pois bem... dá-lhe hackear para conseguir entrar no GDM em modo gráfico... aí o queixo caiu! Parabéns à Oracle... o ambiente é lindo (Gnome, pra variar).

Neste ponto esta mudança do Ubuntu foi positiva, me fez testar várias outras opções para Desktop e, quem depende do desktop e não tem tela sensível ao toque, fica a dica... experimente! De todos os SOs testados segue o saldo:

1. Debian, rola bem melhor em desktop que o novo Ubuntu e, para quem está acostumado com o synaptic ou o "apt-get install", é a pedida.

2. Suse, forte e robusto, usa os pacotes rpm do Red Hat mas resolve as dependêcias sozinho... muito bom.

3. PC-BSD, para quem quer a coisa de verdade... mas com certas facilidades para instalar e configurar.

4. FreeBSD... para machos!

5. Solaris 11, és fã de java? de máquinas virtuais etc.? Pode ser configurado para ficar uma linda penteadeira de camarim de vedete! Vais amar!

Quanto à possível morte do Ubuntu... nem esquente! "Rei morto, rei posto!" diz o ditado.