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