terça-feira, 27 de novembro de 2012

Linux Mint 14


Sabor menta com cobertura de chocolate e canela!


Recheado com as últimas versões dos melhores softwares do mundo Linux, o Mint 14 chega para mostrar a que veio. O anúncio é discreto e clean como a própria distro. Com o codename "Nadia", o novo Linux Mint traz muitas novidades:

Mate 1.4


O MATE é uma versão do GNOME 2 que possibilita, aos usuários o uso da tradicional interface do GNOME. A equipe trabalhou arduamente para melhorar a qualidade do MATE 1.2 e corrigir alguns bugs que estiveram no GNOME 2 por muito tempo e implementando algumas funcionalidades novas.


Cinamon 1.6


O Cinamon 1.6 também está repleto de novidades, inclusive com Workspaces / On Screen Display (OSD) persistentes e altamente configuráveis.


Além disso, os novos ícones são de muito bom gosto e outras funcionalidades tais como lista de tarefas e aplicativos de notificações fazem desta distro uma das mais amadas da galera de TI.

Algumas funcionalidades são bem configuráveis, tais como o MDM (login do Mint) que é altamente configurável, desde a tela de splash até as listas de usuários. O gerenciamento de software também é bem interativo e fácil de usar.


Mas a lista não pára por aí. Veja aqui, as novidades do Mint 14.

Gostou? Quer baixar?  Veja na página de download. Ou use o mirror brasileiro na UFPR:

MATE 32-bit DVD ISO 

MATE 64-bit DVD ISO

Cinnamon 32-bit DVD ISO

Cinnamon 64-bit DVD ISO





domingo, 11 de novembro de 2012

Firefox OS


... porque nem só de Andróides e iOSes vive os Smartphones!

Os smartphones, tablets, gadgets, Raspberries, Arduinos etc. já podem escolher entre vários sitemas operacionais para estes "pequeninos". Claro que o Andróide "rulez" o mercado.

Sim, a equipe do Firefox lançou o Firefox OS. O Sistema Operacional pode ser gravado (flashed) em um Galaxy Nexus ou em um Raspberry Pi. Mas se não tens um "gaguete" destes podes usar o teu próprio navegador Firefox e experimentá-lo dentro do próprio navegador via um simulador baixado e instalado como complemento.

Para baixar o simulador do R2D2B2G vá em http://people.mozilla.org/~myk/r2d2b2g/ e baixe-o para o teu sistema operacional.



Depois de instalado podes ativar uma console "clicando" em

Ferramentas -> Desenvolvedor Web -> Firefox OS Simulator

ou digitando:

resource://r2d2b2g-at-mozilla-dot-org/r2d2b2g/data/content/index.html




Finalmente, ligando o dispositivo no botão à esquerda da página aparece um popup com o FXOS.

Bem, não espere muito. O SO é uma versão alfa, e o próprio simulador é alfa e buguento! Mas podes ter uma idéia do que será o FXOS.

E bom divertimento...

Segue algumas imagens:


 

domingo, 21 de outubro de 2012

TCP Fast Open


... porque a Internet está lotada de informação! Será?

Todos nós que estudamos redes sabemos como o SO lida com a solicitação de conexão e transferência de dados. É o famoso esquema de "handshake" (fig.1) que conhecemos do Transfer Control Protocol (TCP) [1].



Figura 1. TCP handshake

Pois bem, ultimamente, foi proposto um novo modelo para a conexão TCP em que os dados podem transitar já durante o "handshake" e, com isto, pode economizar muito tempo de conexão [2]. Segundo os autores a velocidade de carregamento das páginas pode ser aumentada de 4% a 40% dependendo da conexão de da quantidade de dados transmitidos.

Porque? Por que a Internet está cheia de "firula"... isso mesmo, "viadice". Cada propaganda, cada banner, cada figurinha, cada api em flash, java e os cambáu requer pacotes com cabeçalho, novas conexões ou tempo de espera de novos "handshakes".

A idéia é interessante, pode descongestionar a Internet (um pouco apenas) mas, pode ainda, criar problemas de segurança. Pois a camada de aplicativo fica mais vulnerável (servidor e cliente) enquanto o Kernel não tem como lidar com erros de pacotes e flood de SYN_SEND/SYN_ACK. Não é à toa que o padrão do protocolo TCP proibe inclusão de dados no TCP_SYN e no SYN_ACK antes de completar o handshake.

Pode ser uma nova e promissora tecnologia que poderá reduzir drasticamente o tempo de latência dos serviços de Web. O Kernel 3.6 do Linux já implementa o TCP Fast Open (TFO); pelo menos no lado do cliente. No entanto, eu aconselharia ir "devagar com o andor que o santo é de barro". Antes precisamos nos assegurar de que não teremos furos de segurança neste novo protocolo. Por isso, um excelente campo para pesquisa.



[1] Stevens, W. R. "Unix Network Programming: Networking APIs: Sockets and XTI", 2nd Edition, Prentice Hall, 1998.

[2] Radhakrishnan, S., et.al. "TCP Fast Open", ACM CoNEXT 2011, December 6–9 2011, Tokyo, Japan: in <http://conferences.sigcomm.org/co-next/2011/papers/1569470463.pdf>, acesso em out. 2012.

domingo, 2 de setembro de 2012

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

domingo, 12 de agosto de 2012

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.

terça-feira, 31 de julho de 2012

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

domingo, 15 de julho de 2012

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


terça-feira, 19 de junho de 2012

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

terça-feira, 12 de junho de 2012

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

quinta-feira, 7 de junho de 2012

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

terça-feira, 5 de junho de 2012

UEFI


"Sometimes one pays most for the things one gets for nothing." [1]

A comunidade Free and Open Source Software (FOSS) está agitada, ultimamente porque a micro$oft (M$) resolveu bloquear o boot de qualquer sistema operacional não assinado digitalmente em sistemas equipados com processadores ARM por meio da Extensible Firmware Interface (EFI), melhor dizendo, Unified Extensible Firmware Interface (UEFI). Que é isso?

A ideia da EFI apareceu na criação do Itanium da Intel para resolver as limitações geradas pelo acesso ao modo real (16 bits) dos processadores, o limite de 1 MB do espaço endereçado e outras características típicas dos antigos processadores x86  e seu hardware. Estas limitações passaram a ser inaceitáveis nas plataformas que usavam o Itanium e nas modernas arquiteturas x86.

Em 2005 a Intel passou o EFI versão 1.10 para um Fórum que continuou o trabalho de especificação como Unified Extensible Firmware Interface (UEFI). A especificação da EFI continua pertencendo à Intel e as especificações posteriores da UEFI passaram a pertencer ao fórum [2].

A tecnologia envolvida na interface foi desenvolvida para melhorar certas interrupções da BIOS e permitir acesso a dispositivos mais modernos, implementando:

  • Acesso a endereçamento acima de 1 MB já no Power On Self Test (POST)
  • Acesso a discos de até 2 TB com uma tabela de partição mais completa e confiável.
  • Boot mais rápido
  • Arquitetura CPU-indenpendente
  • Drivers CPU-independentes
  • Ambiente pré Sistema Operacional mais flexível
  • Disponibilidade de rede antes de carregar o SO
  • Modularidade e escalabilidade.

Figura 1: Esquema simples da interação SO e Firmware por meio da interface UEFI.

Enfim, seria uma interface mais moderna com a BIOS e com facilidades muito mais interessantes para os modernos SOs. Mas, como a energia atômica e muitas facas têm dois gumes, a UEFI também. Em modo seguro, é possível gerar uma assinatura digital para aumentar a segurança do SO que roda sobre uma plataforma com UEFI. O que importa é que qualquer usuário pode criar a assinatura e, o mais importante, pode optar por desabilitar o modo seguro [3].

Figura 2: Detalhe da interação UEFI / BIOS

O boot acontece na sequência normal mas o Boot Manager/BIOS interage diretamente com o código da interface EFI/UEFI logo depois do POST, deixando o controle dos Drivers e APIs do manager para a UEFI. Antes de iniciar o sistema operacional, o boot autentica no próprio hardware a permissão de carregar o Operating System Loader. É aí que mora o perigo, pois se pode tornar o hardware "preso" a um sistema proprietário. Isto tem boas e más vantagens...

O que temos assistido recentemente, é que a M$ tem usado estas funcionalidades para tentar bloquear um determinado sistema, requerendo uma assinatura digital proprietária e não permitindo desabilitar o modo seguro nos processadores ARM e x86 de 64 bits.

Acontece que a M$ sempre achou que PC e liquidificador só precisariam de uma tomada (e 64 kB, claro). Veio a Internet e ela teve que "pegar" o código do TCP/IP que foi desenvolvido pela comunidade FOSS; veio, então o browser (navegador) e ela teve que "pegar" o código do Mosaic [4] que também foi desenvolvido pela comunidade FOSS. Não, não vou comentar a história do QDOS e CP/M, do X-Windows da Xerox e nem do DOSShell do Norton Commander.

Mas agora, perdendo terreno para Apple, Linux e Linux/Android, ela tenta desesperadamente uma última cartada... assinar a interface UEFI digitalmente para bloquear qualquer código não assinado. Espero que seja a última, mesmo e que os usuários deixem de ser tão etc..

Este é exatamente o exemplo de como ela pretende fazer o usuário de otário [5]. Me desculpem meus nobres leitores, mas eu diria que isto é mais uma <fêmea do cágado> da M$ e querem saber? Acho que não vai rolar!



Referências:

[1] Albert Einstein.

[2] http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

[3] http://www.uefi.org/home/

[4] Abra o IE e clique em "About IE".

[5] Todo usuário da Microsoft é um beta-tester (Bill Gates na apresentação do Windows 95).

Crédito das imagens:

Imagem topo: http://www.uefi.org/about/logo/

[Fig 1] http://en.wikipedia.org/wiki/File:Efi-simple.svg

[Fig 2] http://en.wikipedia.org/wiki/File:Efi_flowchart_extended.svg



domingo, 3 de junho de 2012

Fedora 17



... the magic of a gnome!


Este blog começou por causa do Unity. Quando o Ubuntu adotou o Unity como window manager (WM) a grande maioria dos usuários Linux (inclusive o próprio Linus Torvalds) sentiram uma certa aversão e abominaram a escolha da Canonical.

Eu mesmo publiquei o primeiro artigo deste blog como "O Rei morreu... Viva o Rei!", afirmando que mudaria de SO e comecei uma grande peregrinação pelo universo dos Linuces. Fiquei espantado ao descobrir quanto eu estava desatualizado neste terreno. Hoje, noto a tendência de todos os SOs que começam a ficar com interface pronta para tablets e smartphones. É a tendência e, fatalmente, acabaremos nos acostumando ao novo modelo.

Mas ainda existe muita resistência à utilização do Unity, embora o próprio Gnome 3 tenha assumido o mesmo "jeitão". Esta resistência tem vários motivos que vão desde o simples "não gostei" até as explicações técnicas sobre limitações de configuração, passando pelas justificativas sobre ergonomia e usabilidade. O fato é que alguns já estão se acostumando ao Gnome 3 e mesmo ao Unity (eu inclusive).

Mas para aqueles que não gostam do Unity, aí está o Fedora 17 (Beefy Miracle) que vem com o Gnome 3 e não deve nada ao Ubuntu. Realmente, o que me atrai no Ubuntu é a quantidade de software disponibilizado em pacotes Debian (.deb) e a sua facilidade de uso mas a equipe do Fedora tem feito um excelente trabalho, mantendo as versões mais recentes e mais estáveis dos softwares em pacotes Red Hat Packet Manager (.rpm).

O que gosto do Fedora é a rapidez e a estabilidade. Afinal o pessoal RedHat/Fedora sempre fez um excelente trabalho. Uma excelente comparação dos dois pode ser encontrado no artigo "When An Ubuntu User Revisits Fedora 17" [1].

Entretanto, nem tudo é doce no Fedora. Apesar de ser uma excelente distro do Linux é necessário fazer muitos ajustes para que ele fique pronto para as atividades comuns de um desktop. Isto se deve ao fato de que os organizadores da distro são conservadores quanto ao uso de plugins proprietários. Mas isto não se torna um problema muito sério, uma vez que se pode instalar este extras com facilidade. A instalação de aplicativos e CODECs, drivers gráficos, Fontes etc. é bastante rápida e existem várias dicas na Web de como fazê-lo [2,3,4,5].

O Fedora 17 é bem mais fácil de instalar que o Windows ou Mac, inclusive no Virtual Box com uma configuração de recursos bem acanhada, sendo bem intuitivo de tal modo que qualquer usuário pode instalá-lo sem dificuldades. O boot do sistema é rápido e o desligamento idem. Na minha opinião, o Fedora 17 é uma distribuição que rivaliza em pé de igualdade com o Ubuntu 12.04 e usar um ou outro depende apenas de gosto e da atividade e necessidade específica de cada um.

Onde encontrar? Aí está o link:

http://fedoraproject.org/get-fedora

Referências:

[1] Bhartiya, S. When An Ubuntu User Revisits Fedora 17 em  http://www.muktware.com/3650/when-ubuntu-user-revisits-fedora-17-review

[2] http://www.unixmen.com/fedora-17-install-codecs-drivers-and-fonts-in-under-5-minutes/

[3] http://www.unixmen.com/how-to-install-media-codecs-for-fedora-1415/

[4] http://www.unixmen.com/how-to-install-nvidia-drivers-in-fedora-13-and-14/

[5] http://www.unixmen.com/install-mp3-players-in-fedora-13/


terça-feira, 29 de maio de 2012

SOs e Frequência da CPU



... quanto vai custar um SO, em termos de processamento?

A relação entre frequência da CPU e consumo de energia é diretamente proporcional. Isto quer dizer que quanto maior a velocidade do processador, maior a frequência de clock e maior o consumo de energia. Em época de gadgets consumo de energia quer dizer menos tempo de bateria e ... sair a caça de tomadas. Em nosso trabalho do dia-a-dia, uma grande parte do tempo perdemos procurando tomada, pontos rede ou de acesso wireless e outros "engates" para nossos celulares, notebooks e tablets. Assim, economia de bateria tem grande importância.

Alguns sistemas operacionais permitem o escalonamento do clock, ou seja, a variação da velocidade da CPU em tempo real. Isto é interessante quando se deseja economizar bateria, principalmente em celulares ou tablets, embora o custo seja de menor velocidade de processamento. Mas também não queremos ficar com um gadget na mão que seja uma lesma! O que é importante é poder calibrar um fator versus outro.

A maioria dos drivers de CPU permitem a variação da frequência do clock (cpufreq_core) para poder oferecer um controle dinâmico da velocidade de processamento e da diminuição do consumo.

Algumas CPUs modernas já fazem o escalonamento, variando entre diversos valores de frequências e de voltagens de operação sem a necessidade de intervenção do kernel do SO. Isto garante a rapidez de troca entre a frequência alta o suficiente para acomodar as necessidades do usuário e baixa o suficiente para economizar energia.

Nestes casos, o SO pode ser configurado para ser mais agressivo em termos de processamento ou mais econômico em consumo mas sempre dentro dos limites estabelecidos [1, 2].

Nos SOs Linux a interface para este controle é definida no kernel como um driver (.../linux-3.x.x/drivers/cpufreq), enquanto que no FreeBSD [3] o controle é estabelecido por um módulo do kernel (/usr/src/sys/modules/cpufreq).

No Linux, o diretório /sys/devices/system/cpu/cpuX/cpufreq/ onde 'cpuX' é cpu0, cpu1 etc., contém todos os arquivos de configuração de cada CPU no sistema em operação e pode ser alterado, seja manualmente ou por algum software, em tempo real.

Claro que pisar no acelerador requer mais combustível e ... é bom não ultrapassar o limite de velocidade. A não ser que tenha como refrigerar o motor com nitrogênio líquido!

Referências:

[1] Pouwelse, J.; Langendoen, K. e Sips, H. "Energy Priority Scheduling for Variable Voltage Processors", http://www.lartmaker.nl/projects/scaling/ (acesso em: 29/05/2012).

[2] mouw, J. A. K.; Langendoen, K. e Pouwelse, J. "LART Lessons Learned: cpufreq", http://www.lartmaker.nl/projects/scaling/ (acesso em: 29/05/2012).

[3] http://doc.fug.com.br/handbook/kernelconfig-config.html

domingo, 27 de maio de 2012

Linux Mint 13



Sim, são muitos sabores de Linux e, agora, Linux com sabores... 

O universo de distribuições Linux é fascinante. Enquanto a MS fica patinando em seu velho DOS com caras novas (que chamam de "janelas"), as distros Linux são um avanço fantástico no paradigma de sistemas operacionais. It's just more fun!

Desde o início, quando Linus Torvalds lançou a idéia, o SO Linux só cresceu em número de distribuições. Aos que ainda confundem, Linux é o kernel do SO, as distros são SO + customizações (que palavra feia!).  Melhor dizendo, SO + pacotes personalizados de software.

No início tínhamos o Yggdrasil [1], Slackware [2], RedHat [3] e Caldera OpenLinux (originalmente Caldera Network Desktop) lançado por ex-funcionários da Novell e depois absorvida pela SCO. Hoje não tenho nem como começar a enumerar os diversos sabores de Linux. Mas este Linux com sabor, vale a pena comentar.



O Linux Mint versão 13 "Maia" [4] é um sistema operacional com kernel Linux para aqueles amantes do Gnome 2. Ele vem em duas edições, o MATE (para gaúchos) e o Cinamon (para mach... oooops... para nerds) não resisti à piada!

É um sistema gratuito com base no Debian Linux e Ubuntu da Canonical e oferece mais de 30.000 pacotes de software gratuitos. Se diz a versão mais utilizada do SO Linux, depois do Ubuntu.

O Mint MATE é uma distro baseada no ambiente gráfico MATE 1.2 que é uma versão expandida do Gnome2/GTK2 com todas as funcionalidades aperfeiçoadas. O Mint Cinamon é construído sobre o Gnome 3 com uma interface tradicional.

O Cinamon ainda não está totalmente estável e ainda não é compatível com todos os tipos de placas gráficas. Por isso, um sistema a ser usado por conta e risco de cada um. Ou seja, ainda para nerds.

O Linux Mint é uma distribuição de instalação bem fácil e amigável, qualquer usuário não terá problemas para instalá-la e ela já vem com diversos programas de desktop previamente instalados, por default.

Para quem quer um sistema operacional excepcional como o Linux e uma interface limpa e amigável, livre do Unit do Ubuntu e com um sabor de chimarrão com menta, esta é uma boa pedida.

Referências

[1] http://www.ibiblio.org/pub/historic-linux/distributions/yggdrasil/

[2] http://www.slackware-brasil.com.br/web_site/

[3]  http://www.redhat.com/

[4] http://www.linuxmint.com/about.php

sábado, 12 de maio de 2012

Dragonfly BSD


... kernel virtual e Hammer (um poderoso martelo de Thor)

O Dragonfly é um sistema operacional (SO) Unix baseado no kernel BSD tal como o FreeBSD, NetBSD e OpenBSD. A última versão é a 3.0.2 Release 2012Q1. Esta versão vem com muitas novidades no suporte a hardware com multiprocessadores, melhoria no sistema virtual de arquivo HAMMER VFS (agora com time domain multiplexing method) que permite melhor performance e balanceamento durante longas operações de armazenamento. Ainda há suporte a encriptação de disco e mais de 10.000 pacotes de software pré-compilados e fontes para ser compilados na árvore pkgsrc.

A instalação é tranquila e não apresenta muitos problemas. Não é uma instalação gráfica mas não apresenta problemas mesmo para quem o instala pela primeira vez. Naturalmente, o conhecimento de sistemas Unix facilita bastante as coisas. O Dragonfly é um sistema como todo BSD, ou seja, um sistema para servidores. O uso do BSD em desktop é mais tranquilo com o PCBSD. Mas se gostas de escovar bits... este aqui é o cara!

Depois de instalado tu tens um sistema Unix nú e crú... É preciso então passar ao refinamento de configurações e, isto significa editar alguns arquivos do diretório /etc (o rc.conf, por exemplo) uma vez que nem mesmo o mouse está configurado. É bem possível que o usuário prefira seguir os passos do manual [1].

Em primeiro lugar é preciso criar o sistema "pkgsrc" que é igual ao do NetBSD e equivalente ao "ports" do FreeBSD. Para isso, faça o login como root e

# cd /usr
# make pkgsrc-create

E pausa para um café... O problema com estes repositórios é o controle de banda imposto pelos servidores. Pow caras, se querem que o sistema decole, é preciso agilitar o processo de download de pacotes de software, como acontece com muitos repositórios de Linux.

Feito isto verifique a documentação [2], para se certificar de que o sistema está pronto para compilar e instalar software. A partir daí, tudo depende do tipo de servidor que o usuário está configurando. E, se for usar o X este terá que ser baixado como binário ou compilado e instalado manualmente. O mesmo acontece para o Gnome, KDE ou qualquer outro gerenciador de janelas preferido [3].

Como todo BSD, o kernel é um canivete suíço. A configuração do sistema pode ser finamente controlada pelos arquivos de configuração e configuração do próprio kernel [4] o que torna o Dragonfly um respeitável membro da família BSD.

Virtual kernel...

Uma funcionalidade que achei muito boa no Dragonfly é a possibilidade de testar o kernel sem ter que ficar dando boot na máquina. Uma verdadeiramente "elegante solução para depurar o kernel e seus componentes" [5].

O kernel é carregado no nível da camada de software (userland) e pode ser testado e depurado sem interferir no kernel real. A capacidade de carregar o kernel no "userland" permite rodar um sistema virtual descartando a necessidade de constantes reboots entre as compilações.



Referências:

[1] http://www.dragonflybsd.org/docs/newhandbook/

[2] http://www.dragonflybsd.org/docs/howtos/HowToPkgsrc/

[3] http://www.dragonflybsd.org/docs/newhandbook/X/

[4] http://www.dragonflybsd.org/docs/newhandbook/Configuration/

[5] http://www.dragonflybsd.org/docs/newhandbook/vkernel/

terça-feira, 8 de maio de 2012

To BSD or not Be




... ou seja, "que BSD vou instalar agora?"


Não é só BSD, mas me pediram e, então, resolvi dedicar este post a uma análise dos SOs Unix livres mais usados e mais indicados para cada tipo de atividade.

Discutir as distribuições de sistemas operacionais é, hoje em dia, uma tarefa complicada. Primeiro porque existe mais de uma centena de tipos de UnixTM e unix-like que são gratuitos e de código aberto. E, segundo, porque cada distribuição está criando especialidades dentro de cada área de atuação profissional (vide meu post sobre o Fedora Spins).

Se deixarmos de lado os SOs próprios para nerds, tipo GNU-Hurd, Inferno, Haiku (ex-BeOS) e os unix-like como Minix e Linux, resta os SOs de kernel BSD [1] e Sistem V. É bom esclarecer que o o kernel Linux, não é um Unix tradicional, embora tenha raízes bem fincadas naquele sistema. Já o kernel BSD é um Unix totalmente POSIX compliant.

Figura 1 História do Unix (Wikipedia [http://en.wikipedia.org/wiki/File:Unix_history-simple.svg])

Na figura 1, pode-se ver os principais sistemas Unix e Unix-like existentes hoje e, como o interesse deste post está voltado para os sistemas Unix free e open source, nos limitamos aos descendentes do BSD e do Sistem V. Os descendentes do BSD a que me refiro são o FreeBSD, o NetBSD, o OpenBSD e o Dragonfly e o descendente do System V (Solaris) é o chamado OpenSolaris (ex-Sun Microsystem, atualmente da Oracle).

O que torna as distribuiões BSD atraentes é, principalmente a sua licença. A licença BSD tem pouquíssimas restrições quando comparada a outras licenças como a GPL (Gnu Public License) ou outras restrições de copyright [2].

As distribuições BSD se diferenciam das distribuições Linux por respeitarem o padrão Unix desenvolvido pela Berckeley Sistem Distribution e atenderem às exigências POSIX. POSIX vem de Portable Operating System Interface e é uma norma definida pelo IEEE organizada pelo grupo 1003 (IEEE 1003) de acordo com as normas ISO/IEC 9945 [3].

Outra característica destes sistemas (FreeBSD, NetBSD e OpenBSD) é o quesito segurança pois são sistemas construídos com foco em redes de computadores e em segurança de rede além, é claro, da preocupação com a estabilidade do núcleo do SO.

Existe muita discussão sobre qual BSD é mais seguro mas todos estão, basicamente, no mesmo nível de segurança. Dependendo da instalação —  que no OpenBSD resulta mais segura por default — é o usuário que acaba definindo o nível de segurança de um sistema. Outro fato é que sistemas BSD tendem a ser instalados por administradores de rede mais experientes que configuram os serviços de acordo com regras mais rígidas. É claro que se deve levar em consideração que o arsenal de ferramentas de segurança destes sistemas é bem grande.

O FreeBSD é, de longe, o sistema que possui maior quantidade de aplicativos e um sistema de instalação com repositórios bem atualizados. O sistema usa o ports (man 7 ports) como repositório de software e que permite a instalação de software pré-compilado ou permite fazer o download dos códigos fonte dos aplicativos e compilá-los localmente, administrando todas as dependências automaticamente.

O OpenBSD é bastante seguro e o mais tradicional dos BSD e o NetBSD é um sistema com um kernel bem "enxuto" totalmente voltado para aplicativos de rede e de roteamento sendo ideal para uso como sistemas de roteadores.

Pode-se dizer que sistemas BSD são sistemas ideais para servidores mas nada impede que se os use como desktop ou mesmo no laptop. Existem algumas versões específicas para estação de trabalho como, por exemplo, o PC-BSD. Usar estes sistemas diretamente requer um bom conhecimento e paciência para configurar e recompilar os aplicativos para que sejam otimizados para cada hardware.

O DragonflyBSD é um kernel BSD customizado que é totalmente open source e gratuito. Este está na minha lista de testes e ainda não tive tempo de analisar com mais detalhes. O que chama a atenção é o sistema de arquivos Hammer com acesso e recuperação do histórico e espelhamento (diferente do modelo do ZFS). Diz-se que o kernel tem um mecanismo de sincronização eficiente e é bem orientado ao paralelismo o que é uma boa funcionalidade para os processadores "multicore" de hoje. (este está na minha lista para um próximo assunto aqui no blog)

Outros sistemas operacionais unix tais como o Oracle Solaris 11, derivado do Sun Solaris 10 possui a versão free e open como o OpenSolaris que roda em arquitetura x86 (veja meu post sobre o Solaris 11). O atrativo deste sistema operacional é a interação com a JVM e o ambiente Java totalmente compativel com a versão da Oracle (antiga Sun Microsystems). O desenvolvedor Java deve considerar uma olhadinha no sistema da Oracle.

Segue, aos interessados, o link para os sites oficiais:

Dragonfly - http://www.dragonflybsd.org/

FreeBSD - http://www.freebsd.org/

NetBSD - http://www.netbsd.org/

OpenBSD - http://www.openbsd.org/

PCBSD - http://www.pcbsd.org/

Oracle OpenSolaris - http://hub.opensolaris.org/bin/view/Main/



Referências:

[1] http://en.wikipedia.org/wiki/Berkeley_Software_Distribution

[2] http://en.wikipedia.org/wiki/BSD_licenses

[3] http://pt.wikipedia.org/wiki/POSIX

Quer saber qual melhor distibuição Linux para você? Experimente este link:

http://www.techradar.com/news/software/operating-systems/10-best-linux-distros-704584

domingo, 29 de abril de 2012

OS e FS



... quem vem primeiro? O ovo ou o pinguim?

Realmente, a questão de quando o kernel sabe sobre o sistema de arquivos (FS) é um paradoxo. O SO precisa estar carregado para iniciar o FS (File Sistem). Mas o SO está no FS... e então? Como fica?

Em outro artigo deste blog ( 0-1 ou On/Off) expliquei que, depois de carregado o firmware e o sistema está pronto, "o programa procura pela palavra 0xAA55 (assinatura de boot) no primeiro setor de um periférico do tipo disco (Floppy, HD, CD/DVD etc.) ou cartão de memória (pen drive, cartão SD etc.)". E aí tem que carregar um FS para poder ler a imagem do kernel, as configurações e os módulos.

Existem duas maneiras de inicar o FS. Uma delas é criando um disco inicial na memória (RAM Disk). A outra é usando um "bootloader" ou boot manager na trilha zero do device de boot que contém o marcador 0x55AA (lembre-se que o x86 é little endian). O primeiro método é, geralmente, usado pelo kernel linux enquanto o segundo é utilizado pelo kernel BSD.

Em ambos os casos é necessário criar um FS mínimo com o kernel e os módulos, o suficiente para permitir a continuidade do processo de boot. No caso do boot manager na trilha zero, este segmento não pode passar de 446 bytes, uma vez que está limitado pela tabela da partição e do setor marcado 0x55AA.

Somente depois de carregado o kernel e o sistema inicial de arquivos é que a raíz do sistema de arquivos (root file system) é montada. No kernel FreeBSD, o boot (man 8 boot) é responsável por iniciar o FS e, posteriormente o loader (man 8 loader) toma o controle do processo.

No kernel Linux, tanto o initramfs (initial ram disk file system) como o initrd (initial ram disk) são responsáveis pelo processo de iniciar um sistema de arquivo na memória para o boot inicial do SO (man 8 init). O initramfs é um sistema interno do kernel e o initrd é a raíz do FS que contém os arquivos no /boot e é passado para o kernel via bootloader.

Somente depois disto que o kernel do SO monta o sistema de arquivos real. No FreeBSD é fácil identificar este momento. Quando as mensagens do boot passam de negrito para sem negrito.

Referências.

Mais informação pode ser obtida na própria fonte do kernel, em:

...linux-x.x.x/Documentation/filesystems/ramfs-rootfs-initramfs.txt

Veja, também, o excelente artigo:

Day, R. The Kernel Newbie Corner: "initrd" and "initramfs"--Some Unfinished Business, in https://www.linux.com/learn/linux-career-center/114923-the-kernel-newbie-corner-qinitrdq-and-qinitramfsq-some-unfinished-business

Crédito da imagem: http://www.h-online.com/imgs/43/3/6/8/3/5/2/a345f5e7c547062f.jpg

sexta-feira, 20 de abril de 2012

Linux e processamento paralelo


SIMD e Extensões de código de CPU no Linux

O cálculo com ponto flutuante sempre foi o nó górdio para os sistemas operacionais. Sua importância se revela na própria unidade de medida de velocidade de processamento: FLOPS (FLoating-points Operations Per Second) ou número de operações de ponto flutuante por segundo. 1997 foi um ano decisivo para os sistemas operacionais. Os fabricantes de chips para CPU disputavam nas raias da velocidade de processamento e implementavam registros de 64 e 128 bits para cálculos com ponto flutuante (Floating Point). Os 3 principais fabricantes (Intel, AMD e Cyrix) disputavam ombro a ombro no ranking de velocidade.

 A AMD disparou na frente com o seu processador K6-2 e, posteriormente o Athlon, que utilizavam a tecnologia apelidada de 3DNow, além do suporte a MMX, memória cache secundária e Accelerated Graphics Port (AGP). A tecnologia 3DNow permitia o cálculo com números de ponto flutuante em registros de 64/80 bits, com instruções específicas para o processador que permitiam a operação no mesmo registro.

 A resposta da Intel foi rápida. Quando a Intel lançou os Pentium III foram criadas 70 novas instruções de código e 8 registros para estes processadores, com a finalidade de incrementar o desempenho do processamento de ponto flutuante (Floating-Point Unity - FPU). Estas instruções extendidas do conjunto de instruções do processador foi denominada de Streaming SIMD Extensions (SSE). A tecnologia SSE implementava os registradores XMM de 128 bits. A vantagem da tecnologia da Intel é que a operação podia ser feita com até 4 números no mesmo registro.

As extensões foram sendo otimizadas e os processadores passaram a disponibilizar 8 registros de 128 bits (XMM0 ... XMM7 nos processadores com suporte a SSE) e depois 16 registros de 128 bits (XMM0 ... XMM15 nas CPUs com suporte a SSE2 em diante). Atualmente, o suporte é de até 16 registros de 256 bits (YMM0 ... YMM15 nas CPUs com suporte a AVX). Nas CPUs com suporte a AVX os bits de 0-127 dos registros YMM0 ... YMM15 funcionam como registros XMM.


A tecnologia AVX (Advanced Vector Extensions) implementa novas instruções do processador para operar sobre os registros YMM, usando até 3 endereços de fonte de dados e um endereçamento de destino de dados em uma única instrução do tipo Single Instruction Multiple Data (SIMD).

Em um sistema multitarefa preemptivo como o Linux o uso destas extensões de SIMD requer uma habilidade adicional no controle dos registradores. Por isto o kernel do SO tem que estar preparado para lidar com registros extendidos. Por exemplo, quando o sistema passa o controle de um processo para outro, os registros SIMD do processo anterior têm que ser salvos e o novo conjunto de registros SIMD do processo que entra para rodar é carregado no processador. O SO tem que estar pronto para lidar com estes registros extendidos e gerenciá-los apropriadamente.

No kernel do linux (3.x) o suporte a este tipo de processamento é fundamental para a paralelização de algorítmos e o suporte a SMP (Symetric MultiProcessing) em processadores dualcore, quadricore, i5, i7 etc. e isto depende do suporte no kernel a instruções extendidas SSE / SSE5 e AVX do processador.

Para ver o suporte do processador a estas extensões, use o comando:

cat /proc/cpuinfo |grep flags
 O comando retorna o campo "flags" de cada núcleo ou processador.

Allternativamente, pode-se usar o nome do flag da extensão. Por exemplo:

cat /proc/cpuinfo |grep sse

Normalmente, os sistemas operacionais mais modernos já são configurados para o suporte às extensões da CPU. No kernel, fica tudo definido nos arquivos:

/src/linux-.../arch/x86/include/asm/processor.h
/src/linux-.../arch/x86/include/asm/sigcontext.h
/src/linux-.../arch/x86/include/asm/xsave.h
/src/linux-.../arch/x86/kernel/cpu/common.c
/src/linux-.../arch/x86/kernel/xsave.c

O processamento paralelo é vantajoso para cálculos matemáticos de alto desempenho tanto para processamento em computação científica como em processamento de sinais de áudio e imagem para execução, em tempo real, de aplicativos multimedia. No entanto, o rendimento é dependente da fração do programa que pode ser paralelizada e do número de núcleos envolvidos no algorítmo em paralelo. A relação é de

`V=frac{n}{(n-1)f + 1}`

onde V é a velocidade de processamento, n é o número de processos paralelos e f é um fator de paralelismo (veja lei de Amdahl).

Normalmente, programas que utilizam as bibliotecas do BLAS (Basic Linear Algebra Subprograms), LAPACK (Linear Algebra PACKage) e ATLAS (Automatically Tuned Linear Algebra Software) podem usar o processamento vetorial avançado provido por estas extensões da CPU.

Além disso, existem outras aplicações que podem usar estas extensões para processamento, tais como: funções transformadas FFT, Wavelet e outras aplicações para sistemas lineares; algoritmos de RNG (Random Number Generator) para funções de distribuição estatística; aplicações para criptografia; e, ainda, rotinas numéricas em FORTRAN e C/C++ de software como (Octave, Scilab, Matlab e Matematica).


...
Dave Bowman: Yes, I'd like to hear it, HAL. Sing it for me.
HAL: It's called "Daisy."
[sings while slowing down]
HAL: Daisy, Daisy, give me your answer do. I'm half crazy all for the love of you. It won't be a stylish marriage, I can't afford a carriage. But you'll look sweet upon the seat of a bicycle built for two.

Referências:

http://pt.scribd.com/dbrunecz/d/57793168-Optimizing-Assembly

http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011/compiler_c/intref_cls/common/intref_avx_details.htm

http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

http://en.wikipedia.org/wiki/Advanced_Vector_Extensions