Haiku

Não... não, o BeOS não morreu. Ele se transformou!

E para melhor, na forma do Haiku. Agora em 64 bits. Ok, sei que muitos não conhecem o BeOS e, muito menos, sua nova personalidade ― o Haiku. Então senta que lá vem história.

O BeOS apareceu em 1991 para concorrer com o Mac OS e o Microsoft Windows mas baseado em uma interface gráfica derivada do X consortium e com implementação de multiprocessamento simétrico, capacidade de I/O modular, multithread pervasiva, multitarefa preemptiva e um sistema de arquivo de 64 bits. Tudo isso num tempo que ainda não havia Linux.

Foi um sistema tão bem feito que a Apple cogitou comprar a Be Inc. mas não se acertaram no preço e ela resolveu adquirir a NextStep e trazer o Jobs de volta. O mais interessante é que o Unix da AT&T feito para rodar no Hobbit acabou sendo portado para a arquitetura CISC com o nome de BeOS e chegou a fazer sucesso como desktop para x86. Foi comprada pela Palm Inc. para se converter no PalmOS Cobalt que não decolou e a última versão open foi a alpha 3.

Como era um sistema aberto, alguns grupos retomaram de onde haviam parado e criaram o projeto Haiku [1]. O sistema é simples, fácil de usar e de bastante bom gosto. Além de ser bem poderoso e voltado para multimídia.

Ultimamente, depois do summer of code 2012, o sistema operacional na versão de 64 bits está pronto. Muitos aplicativos ainda têm que ser compilados para esta arquitetura mas o sistema básico já está pronto. Alguns bugs ainda devem ser resolvidos, principalmente o work around com opção -mno-red-zone do GCC para contornar as especificações da ABI do AMD64. Mas parece que já estão trabalhando no problema e logo estará resolvido.

O trabalho maior será portar aplicativos e drivers para 64 bits mas é uma questão de tempo. A instalação no Virtualbox ainda ficou bem "capenga" mas consegui rodar sem maiores problemas. O visual é muito bonito e tem um toque dos antigos MACINTOSH. Para que gosta de experimentar sistemas operacionais, vale a pena baixar e brincar com ele.

Aí está um sistema que pode amadurecer rápido e chegar para ficar no campo dos desktops, hoje um tanto abandonados pelos tablets e smartphones.

[1] https://www.haiku-os.org/about

Gnome OS

... são seres elementais, ligados à terra e aos elementos minerais.

Mas para quem é da área de computação e informática, GNOME é uma abreviatura de Gnu Network Object Model Environment e é um dos ambientes gráficos mais utilizados nas distribuições Linux e outros Unix, como o Solaris, por exemplo. Mas parece que ele almeja mais do que ser apenas o Window Manager (WM).

O Blog Ubuntued publicou uma matéria de Luciano Fernandes sobre o novo sistema operacional do Gnome, o Gnome OS [1]. Bem, não se assanhem... acho que ainda demora um pouco para isto virar realidade. Primeiro porque o Gnome 3 não está tão preparado para assumir um papel de SO assim, sem a dependência de muitas libs do Linux; segundo porque ainda falta muito para a fusão GTK com SDK; e terceiro, não existe nenhum fabricante de hardware interessado em distribuir um gadget com o Gnome embarcado.

Pois é, integrar as libgtk, libqt e libpy com o SDK não será um processo simples e tem que ser feito porque o centro das APIs do Gnome estão bem apoiadas nestas bibliotecas. Existe muita promessa para a próxima versão. Entretanto, será que o Gnome 4, que virá no próximo ano, emplacará numa empreitada desta? Mera especulação.

Num ponto o autor do artigo do Ubuntued tem razão:

"Enquanto alguns desenvolvedores e usuários (Incluindo o Linus Torvalds) se concentram em criticar o GNOME 3.6, alguns desenvolvedores estão pensando a longo prazo."

Parece que o próprio Allan Day (Gnome.org) já está convencido de que terá que adequar o Gnome aos gadgets, tablets, smartphones, ultrabooks e toda a nebulosidade preconizada (a computação em nuvem)[2, 3]. E é a tendência mesmo. Vejam que mesmo a Microsoft ― que muitos apostam estar quebrando a cara com o Metro ― já mudou o paradigma do seu WM, o Windows 8.

Em um artigo em seu blog, Allan Day assume que a idéia de um OS Gnome existe há vários anos. Ele afirma que este OS não é um sistema que possa concorrer com as distros Linux e nem predente substituí-las. Ele afirma que uma instalação standalone do Gnome tem a finalidade de criar uma plataforma experimental de desenvolvimento. 

 

Mas como eu disse, falta muito ainda. Primeiro a equipe do Gnome terá que alinhar o SDK com GTK e estabilizar as APIs do Gnome. Isto significa alterar o core destas APIs para que elas funcionem neste novo ambiente. Muitas delas, estão hoje presas a bibliotecas GTK e até do QT. Ok, sei que muitos já viram o Gnome integrado ao Java no Solaris 9.0 e podem lembrar como os dois se deram bem. Mas não é a mesma coisa que portar o cerne de APIs como o Nautilus, por exemplo, para rodar sobre o SDK.

Mas vamos ser mais pragmáticos neste ponto. Hoje, as distribuições vêm com uma Graphical User Interface (GUI) padrão. O Ubuntu é uma instalação da Canonical centrada no Unity. É preciso lembrar que o Unity é uma casca que roda sobre o Gnome, mas para o usuário é uma interface gráfica independente, muito embora vários aplicativos sejam do próprio Gnome. Já não é o caso do XFCE ou do LXDE que são WM independentes e são default em distribuições Debian, Suse e mesmo alguns spins do Fedora (RedHat). Então não se pode dizer que o Gnome OS não tenha chance. Sorry Linus, tem sim, e muita!

Será então uma tendência? Somente o tempo dirá. Mas vamos ter ainda o aparecimento de Firefox/Mozilla OS, Chromium OS e muitos outros na parada... Viva a diversidade!


[1] Fernandes, L. "Gnome OS ja tem data de lançamento", em: http://forum.ubuntued.info/viewtopic.php?f=37&t=2197#p19556&utm_source=buffer&buffer_share=90bff

[2] O'Brein, T. "GNOME OS plans detailed: desktops and tablets and smartphones, oh my!", em: http://www.engadget.com/2012/08/08/gnome-os-plans-detailed/

[3] Picão, M. E. "Pode vir aí o GNOME OS: uma distro específica do GNOME", em: http://www.hardware.com.br/noticias/2012-08/gnome.html.

btrfs

Butterflies ou butterfiles, aí vem o btrfs.

Desde a evolução do ext3fs, em 2006/2007, começaram as discussões sobre funcionalidades dos sistemas de arquivos e como deveria ser feita uma reforma neste campo. O ext4fs pode ser considerado um "cul-de-sac" porque, depois dele, as funcionalidades requeridas de um novo sistema de arquivos dependeriam de um desenvolvimento do zero. Não vou detalhar aqui quais as implicações de se criar um ext5fs com as funcionalidades do Zeta File System (ZFS) para Linux por exemplo. A partir daí várias propostas vieram no sentido de se criar um filesystem (FS) mais moderno e totalmente reescrito.


Jörn Engel [1] propos um sistema de arquivos que armazenaria a árvore de diretórios no próprio dispositivo, ao invés de contruí-la na hora da montagem (mount). Assim, estando no dispositivo, reduziria consideravelmente o tempo de montagem e o uso de memória. Este sistema chama-se LogFS e encontra-se no kernel do Linux em .../linux-x.x.x/fs/logfs.

A Nippon Telegraph and Telephone Corporation (NTT) propos o NILFS [2] que é um sistema de arquivo com suporte a versão temporal de todo o sistema, permitindo também o snapshoting contínuo e garantindo ao usuário a recuperação de arquivos sobrescritos ou deletados. O NILFS está no kernel linux em .../linux-x.x.x/fs/nilfs2 (veja especialmente o arquivo Kconfig).

O BTRFS (B-Tree File System), chamado de "butter" file system ou "better" file system é um sistema de arquivo incluído no kernel do Linux ainda em modo experimental (veja .../linux-x.x.x/fs/btrfs/Kconfig). Ele tende a ser um extensão natural do extended file system (ext3fs/ext4fs) com várias funcionalidades extras, tais como copy on write (CoW), tolerância a falha e suporte a múltiplos dispositivos, como o ZFS (veja meu post sobre o ZFS).

O btrfs suporta arquivos e sistemas de arquivos grandes da ordem de 16 EiB (16 quintilhões de bytes), oferece um gerenciamento integrado dos volumes, suporte a RAID, mantém a integridade dos dados e writable snapshot usando CoW.

Começou a ser desenvolvido por Chris Mason (Oracle) [4] a partir da idéia de Ohad Rodeh  de CoW implementado sobre B-tree [5]. Hoje em dia, o projeto do btrfs está em franco desenvolvimento por vários grupos de usuários Linux (Canonical, RedHat, SUSE etc. e outras companias como IBM, Intel, HP, Fugitsu e a própria Oracle).

O suporte ao btrfs, embora experimental, já se encontra no kernel Linux desde a versão 2.6 e pode ser visto com detalhes em .../linux-x.x.x/fs/btrfs. Mais precisamente, o arquivo btrs_inode.h mostra detalhes das estruturas envolvidas neste sistema de arquivos.

Criando um sistema de arquivos BTRFS

Para criar um sistema btrfs é preciso apenas um comando. Digamos que temos 2 discos físicos com 5 GB (/dev/sdb e /dev/sdc). Pode-se usar o comando:

# mkfs.btrfs /dev/sdb /dev/sdc

Isto cria um sistema de 10 GB btrfs que deve ser montado como /dev/sdb apenas, pois o btrfs cuida do restante. Por exemplo:

# mount /dev/sdb /mnt

Se tentarmos verificar o tamanho do disco montado:

# df -h /mnt

o sistema retornará:

Filesystem       Size   Used   Avail   Use%   Mounted on
/dev/sdb          10G    56K    8.0G     1%    /mnt


Para mais detalhes, o comando btrfs (ferramenta de administração):

# btrfs filesystem df /mnt

Data, RAID0: total=1.00GB, used=0.00
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=1.00GB, used=24.00KB
Metadata: total=8.00MB, used=0.00

Mais detalhes e referências, veja: https://btrfs.wiki.kernel.org/index.php/Main_Page


Referências:

[1] Engel, J. Mertens, R. LogFS - finally a scalable flash file system, 2005 em:
http://www.informatik.uni-osnabrueck.de/papers_pdf/2005_07.pdf

[2] NTT Labs, em: http://www.nilfs.org/en/

[3] https://btrfs.wiki.kernel.org/index.php/Main_Page

[4]  https://oss.oracle.com/projects/btrfs/

[5] Rodeh, O. B-trees, Shadowing, and Clones, ACM Transactions on Storage, to appear, February 2008. Copyright ACM 2007. em: http://www.cs.tau.ac.il/~ohadrode/publications.html

[6] Bierman, M. e Grimmer, L. How I Got Started with the Btrfs File System for Oracle Linux, pub. 2012 em: http://www.oracle.com/technetwork/articles/servers-storage-admin/gettingstarted-btrfs-1695246.html

Vector Linux

... para os amantes do Slack!

Finalmente terminaram as atribuições de final de semestre (correções de provas, trabalhos, notas etc.) e posso voltar a escrever. Existem alguns assuntos "na fila" mas escolhi o Vector Linux para reabrir. Primeiro porque ele é baseado em uma das mais antigas distros de Linux, o Slackware [1]; e segundo porque ele é um "lego". Em sua versão 7.0, o sistema operacional inaugura sua versão de 64 bits.

"...keep it simple, keep it small and let the end user decide what their operating system is going to be." [2]

O pessoal do Vector Linux tem uma filosofia de deixar tudo simples e mínimo, exatamente como um "lego" onde o usuário é quem vai definir o que precisa para deixar o seu sistema operacional mais adequado às suas necessidades.

Basicamente, o sistema é distribuído com o leve e rápido Xfce-4.8, configurado com um tema simples e agradável, com Dock e tudo mais. Além disso, já vem com os aplicativos de multimídia, tais como tocadores de DVD, áudio e os principais CODECs de vídeo; e os plugins de Java instalados e funcionando perfeitamente. Como o window manager é leve, parece até que os aplicativos em Java rodam mais à vontade.

Os principais aplicativos de gráficos (GIMP, visualisador de PDF etc.) já vêm instalados, bem como os de Internet, tais como Firefox, pidgin, xchat e outros FOSS (Free and Open Source Software). Importante ressaltar a atualidade dos drivers de suporte a hardwares recentes, principalmente redes wireless, câmeras e placas de rede.

O Vector Linux vem em 3 sabores [3]:

Standard: Tipicamente um desktop de uso em casa/escritório, com os aplicativos comuns de um desktop, tais como editores, browsers, comunicação, multimídia etc..

Light: Uma versão para hardware mais modesto com suporte a todos os aplicativos de desktop, com ambiente gráfico baseado em LXDE, IceWM e JWM.

SOHO: Uma versão para alta performance e computação científica, com desktop baseado em KDE 4 e aplicativos de desenvolvimento e de maior performance.

Para os fãs do Slackware, é uma boa pedida para começar o próximo semestre de sistema novo.

Happy Linuxing!


Referências:

[1] http://www.slackware.com/
[2] http://www.vectorlinux.com/
[3] http://vectorlinux.com/downloads

Fork e Thread

Evite o fork() em caso de multithread...

Em sistemas Unix e Unix-like, quando uma chamada de sistema cria um fork, o processo faz uma cópia de si mesmo que chamamos de processo filho (child process). O SO pode diferenciar um do outro pelo retorno da função fork() que é zero no processo filho, enquanto que retorna o PID do processo filho no processo pai.

Quando vários processos rodam concomitantemente no mesmo processador, o kernel do SO pode dividí-los em unidades de processamento que podem ser agendadas segundo uma multiplexação por fração de tempo (time-slice multiplexing). Estas unidades são chamadas de threads de um processo. Processos podem rodar várias threads concorrentemente (multithread process) que otimiza a utilização da memória. Threads de um processo podem compartilhar recursos e memória, o que dois processos não podem fazer, por terem address space diferentes.

A maneira como o SO lida com os processos depende de como o processo foi programado e como ele realiza as chamadas de sistema (system call). Quando dois processos iguais correm em um mesmo sistema Unix, o kernel faz o fork() do processo e cria um novo processo (processo filho) com um novo address space. Além disso, o fork precisa do IPC (InterProcess Comunication) para trocar informações entre o processo pai e o processo filho, depois do fork. [1]

Alternativamente, o SO pode usar o recurso de múltiplos threads de um mesmo processo. Isto é mais vantajoso porque a comunicação e compartilhamento de recursos entre as threads é mais fácil (por estarem no mesmo address space) [2].

Existe, porém, um problema decorrente da chamada de um fork() em um processo multithread. Por exemplo, em um processamento multitarefa um fork() registra no processo pai o PID do processo filho. Mas, quando um thread em uma tarefa multithread executa um fork() qual delas conteria o processo filho? Se bem que é uma situação evitada sempre que possível, existem situações onde o fork do processo multithread resulta no processo filho (também multithread) e o término do processo filho precisa retornar informação para o processo pai via IPC.

Bem, pode ser que o processo filho contenha um thread correspondente ao thread do processo pai. Ou, talvez, é possível igualar o número de threads do processo filho ao do processo pai de tal forma que haja correspondência dos threads.http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them

Mas, antes de implementar um fork() em um processo multithread, é preciso planejar muito bem. Normalmente, o processo "forked" deve ser criado como uma única thread e, se um processo multithreaded chama a função fork(), o novo processo deve ser um réplica exata de todas as  threads, bem como de seu espaço de endereçamento.

Por isso,  Pense duas vezes [3] antes de misturar fork() e threads.

Referências:

[1] Stevens, W. R. Unix Network Programming, 2nd Ed., Vol. 1, Prentice Hall, NJ, 1998.

[2] Stevens, W. R. Advanced Programming in the Unix Environment, Addison-Wesley, Reading, Mass., 1992

[3] http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them

Chamadas de sistema

Chamadas em C... cadê o C?

A postagem de hoje é um pouco técnica mas bem interessante. O objetivo é dar uma espiada no problema do "ovo ou a galinha". Bem, o kernel do Unix é escrito em C e, consequentemente, alguns símbolos das bibliotecas teriam que ser resolvidos nas libs em estão em /usr/lib ou /lib. Acontece que, quando o kernel está carregando, o sistema de arquivos ainda não está disponível. Então... o que vem primeiro? O ovo ou a galinha?

Como já vimos anteriormente em outras postagens deste blog, o kernel (ou núcleo) do sistema operacional (SO) é o responsável por grande parte do gerenciamento do sistema. Assim, ele fica responsável pelo gerenciamento da memória, gerenciamento das interfaces de entrada e saída (I/O), controle das interrupções etc., além das operações de iniciar o próprio sistema [1].

Em alguns kernels (microkernels  e exokernels ) estes serviços são executados no user space (userland) mas, mesmo assim, eles ficam disponíveis por meio das chamadas de sistema (system calls). Qualquer programa que rode no userland ou no kernel space pode disparar estas chamadas de sistemas que são as interfaces entre um processo e o SO.

As chamadas de sistema são feitas por meio de funções em C do tipo read, write, open, exit, por exemplo. O FreeBSD tem cerca de 500 chamadas de sistema, enquanto o Linux tem cerca 300. Algumas delas usam bibliotecas do GCC mas existe um detalhe importante: quando o kernel está carregando o SO, ele não tem acesso, ainda, às bibliotecas e cabeçalhos do C ou do GCC porque o sistema de arquivos ainda não está montado. Isto significa que o kernel tem que ter suas próprias bibliotecas e cabeçalhos.

Então, porque não implementar a biblioteca C dentro do código do kernel? Bem, basicamente é o que se faz, mas com muitas restrições.

1. A libc tem outras funcionalidades não necessárias ao kernel e que pode apenas servir para aumentar o tamanho do kernel depois de compilado, por exemplo, ao inserir o string.h do gcc no kernel, as referências a memcpy(), memset(), memcmp() etc. estariam no código mas não seriam usadas no kernel space.
2. A implementação, no kernel, requer que ela tenha como chamar o sistema (system call) de dentro do kernel [3].
3. Outros símbolos e formatos são necessários para funções implementadas no kernel como, por exemplo, a função printf().

O exemplo a saída de mensagens do sistema durante o boot que em ANSI C pode ser implementada com a função printf(). apresenta o problema de que o stdio.h e a libc ainda não estão disponíveis. Assim, a função tem que estar definida no próprio código do kernel. No Linux. por exemplo, a função é chamada de printk() que está em .../linux/kernel/printk.c [4].

Exemplos:

printk("The address of my_var is %p\n", &my_var);

printk(KERN_DEBUG "*** This is a debug message. ***\n");

Os formatos mais usados na função printk() são o KERN_INFO e KERN_DEBUG. Estes formatos KERN_* são definidos no .../include/linux/kernel.h.


Referências:

[1] http://www.makelinux.net/kernel_map/

[2] Bach, M. http://www.vivaolinux.com.br/artigo/Novidades-do-Kernel-2.6.35J., The Design of the UNIX Operating System, Prentice Hall, 1986.

[3] Tanenbaum, A. S., Modern Operating Systems, Prentice Hall, 1076 pages, 2008.

[4] Love, R. Linux Kernel Development, Novell Press, 2005.

Crédito da imagem: http://www.vivaolinux.com.br/artigo/Novidades-do-Kernel-2.6.35

Diablo3 no Linux

"Eu uso Windows porque gosto de jogar..." Ha... ha!

Se tu és daqueles que diz que usa Windows porque gosta de games e Linux não tem games, estás enganado. Nem precisas ficar preocupado porque não poderás jogar Diablo III! Podes sim. E aqui vai uma dica de feriado (embora um pouco off topic do blog). Divirtam-se mas deixem um tempinho para estudar para as provas.

Primeiro tens que saber se tens a configuração de hardware adequada, por exemplo placas de vídeo, memória RAM etc. e, depois, se teu sistema tem as bibliotecas adequadas. O Ubuntu 12.04 roda bem em 32 bits. O sistema operacional em 64 bits não tem todas as bibliotecas do OpenGL necessárias para rodar o programa. Então é bom ler sobre o PlayOnLinux.

Mas os passos são simples (Ubuntu 12.04):

1. Instale o Wine [1]: use o 'pkg_add install wine',  a central de programas ou o Synaptic.

2. Instale o PlayOnLinux [2]: idem.

3. Faça o Download do Diablo III: Se tiver o DVD, pule os passos 4 e 5.

4. Se não tens grana pro DVD, use uma conta do Battle.net para baixar o instalador [3].

5. Clique no instalador e escolha "Abrir com o Wine Loader". E baixe o Diablo III.

6. Abra o programa "PlayOnLinux", siga as instruções de configuração inicial e, na interface principal clique em "install" e procure o programa do Diablo III.

7. Escolha o método de instalação (DVD ou o setup do Diablo) e clique em "Next" até aparecer uma nova janela de setup (agora do programa) que desaparece em alguns segundos para dar lugar à tela de instalação do Diablo III.

Have Fun!!!

Referências:

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

[2] http://www.playonlinux.com/

[3] http://eu.battle.net