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/