Ted Ts'o fala à Linux Magazine

Em passagem por Bruxelas, na conferência Fosdem 2009, Theodore Ts'o, um do mais proeminentes desenvolvedores do kernel Linux, falou à Linux Magazine sobre sua situação na Linux Foundation, sobre o novo Ext4, discorreu sobre o ainda experimental BtrFS e falou também como foi o seu início no mundo Linux.

*---*---*---*---*---*---*---*---*---*---*

Mais um vídeo ai pra galera. Nesse ai o repórter me quebrou as pernas, a última pergunta eu não entendi o que ele quis dizer, então se você entendeu, manda aí nos comentários.

*---*---*---*---*---*---*---*---*---*---*

Para correções, críticas & derivados, manda bala nos comentários ou pelo email: syph0s at hotmail dot com.

Kernel Linux em Poucas Palavras – Parte 2

Se tiver alguma dúvida, consulte os PDFs em inglês disponibilizados no fim do post.

*---*---*---*---*---*---*---*---*---*---*

2. Requisitos para Compilar e Utilizar o Kernel

Esse capítulo descreve os programas que você precisa para configurar um kernel, compilá-lo e inicializá-lo com sucesso. É uma boa idéia consultar os arquivos Documentation/Changes para verificar o número especifico da versão que você tem de cada ferramenta descrita nesse capítulo. Esse capítulo foi baseado no kernel 2.6.18 e descreve as versões das ferramentas que funcionam com esse kernel. Se você está usando um kernel diferente, por favor verifique se você tem as versões certas como especificadas nesses arquivos ou algumas coisas podem não funcionar corretamente e pode ser bem difícil determinar o que deu errado.

Ferramentas para Compilar o Kernel

A maioria das distribuições Linux oferecem um opção d instalação para instalar uma gama de pacotes de modificações do kernel. Se a sua distribuição fornece essa opção, é mais fácil instalar isso em vez de tentar catar individualmente todos os programas que são necessários para essa tarefa.

Somente três pacotes são necessários para compilar um kernel com sucesso: um compilador, um linker e a ferramenta make. Essa seção descreve o conteúdo de cada pacote.

Compilador

O kernel Linux está escrito na linguagem de programação C, com uma pequena quantidade de linguagem assembly em alguns lugares. Para compilar o kernel, o compilar em C gcc deve ser usado. A maioria das distribuições Linux tem um pacote entitulado gcc que deverá ser instalado. Se você quiser baixar o compilador e compilá-lo você mesmo, você pode encontrá-lo em http://gcc.gnu.org.

Para a versão 2.6.18 do kernel, a versão 3.2 do gcc é a mais antiga que pode compilar corretamente um kernel funcional. Esteja avisado que instalar a versão mais recente do gcc nem sempre é uma boa idéia. Algumas das versões mais novas do gcc não compilam o kernel corretamente, portanto, ao menos que você queira ajudar o debug do compilador, não é recomendável que você as experimente.

Para determinar qual versão do gcc você tem no seu sistema, rode o seguinte comando:

$ gcc --version

Linker

O compilador C, gcc, não faz toda a compilação por si só. Ele necessita de um conjunto de ferramentas adicional conhecido como binutils para linkar e montar os arquivos fonte. O pacote binutils também contém ferramentas úteis que podem manipular arquivos de objetos de diversas maneiras, como visualizar o conteúdo de uma biblioteca.

O binutils pode ser encontrado normalmente num pacote chamado (sem surpresas) binutils. Se você quiser baixar e instalar o pacote você mesmo, você pode encontrá-lo em http://www.gnu.org/software/binutils.

Para a versão 2.6.18 do kernel, a versão 2.12 do binutils é a mais antiga que pode linkar o kernel corretamente. Para ver qual versão do binutils você tem instalada no seu sistema, rode o seguinte comando:

$ ls -v

make

O make é uma ferramenta que percorre a árvore do código do kernel para determinar quais arquivos precisam ser compilados, para então chamar o compilador e outras ferramentas de compilação para fazerem a tarefa na construção do kernel. O kernel exige a versão GNU do make, que pode ser normalmente encontrado num pacote chamado make na sua distribuição.

Se você deseja baixar e instalar o make você mesmo, você pode encontrá-lo em http://www.gnu.org/software/make.

Para a versão 2.6.18 do kernel, a versão 3.79.1 do make é a mais antiga a compilar o kernel corretamente. É recomendado que você instale a última versão estável do make, já que as versões mais novas são famosas por serem mais rápidas no processo de compilação de arquivos.

Para ver qual a versão do make que você tem em seu sistema, rode o comando a seguir:

$ make --version

Ferramentas para Utilizar o Kernel

Enquanto a versão do kernel que está rodando normalmente não afeta qualquer aplicação do usuário, existe um pequeno número de programas que realmente dependem de certa versão do kernel. Essa seção descreve várias ferramentas que provavelmente já estão instaladas no seu sistema Linux. Se você atualizar o seu kernel para uma versão diferente daquela que veio com a sua distribuição, alguns desses pacotes possivelmente precisarão ser atualizado para que o sistema funcione da forma apropriada.

util-linux

O pacote util-linux é uma coleção de pequenas ferramentas que fazem uma grande quantidade de tarefas. A maioria dessas ferramentas lidam com a montagem e criação de partições de discos e com a manipulação do relógio do hardware no sistema.

Se você deseja baixar e instalar o util-linux você mesmo, você pode encontrá-lo em http://www.kernel.org/pub/linux/utils/util-linux.

Para a versão 2.6.18 do kernel, a versão 2.10 do util-linux é a mais antiga que funciona corretamente. É recomendado que você instale a última versão desse pacote, já que a nova versão suporta novas funções adicionadas ao kernel. A montagem com a opção bind é um exemplo de uma opção dos novos kernels e uma nova versão do util-linux é necessária para ter essas funções funcionando corretamente.

Para ver qual a versão do util-linux você tem instalada no seu sistema, rode o seguinte comando:

$ fdformat --version

module-init-tools

O pacote module-init-tools é necessário se você deseja usar os módulos do kernel Linux. Um módulo do kernel é um pedaço de código carregado que pode ser adicionado ou removido do kernel enquanto o kernel está rodando. É útil compilar drivers de dispositivos como módulos e então carregar apenas aqueles que correspondem ao hardware presente no sistema. Todas as distribuições Linux usam módulos para carregar apenas os drivers e opções necessários para o sistema baseado no hardware presente, em vez de ser forçado a compilar todos os drivers e opções possíveis no kernel como um grande código único. Os módulos economizam memória por carregar apenas o código que é necessário para controlar a máquina da forma apropriada.

O processo de carregamento de módulos do kernel sofreu uma mudança radical na série 2.6 do kernel. O linker para o módulo (o código que decodifica todos os símbolos e descobre como unir os pedaços na memória) agora está acoplado no kernel, o que torna as ferramentas do userspace bem pequenas. Distribuições antigas têm um pacote chamado modutils que não funcionam corretamente com o kernel 2.6. O pacote module-init-tools é o pacote que você precisa para fazer o kernel 2.6 funcionar corretamente com os módulos.

Se você quiser baixar e instalar o pacote module-init-tools você mesmo, você pode encontrá-lo em http://www.kernel.org/pub/linux/utils/kernel/module-init-tools.

Para a versão 2.6.18 do kernel, a versão 0.9.10 do module-init-tools é a mais antiga a funcionar corretamente. É recomendado que a última versão desse pacote esteja instalada, já que novas funções adicionadas ao kernel podem ser usadas pela versão mais recente desse pacote. Colocar os módulos na blacklist previne que eles sejam carregados automaticamente pelo pacote udev é uma das opções que está presente na mais recente versão do module-init-tools, porém não está nas versão antigas.

Para ver qual versão do module-init-tools está instalada no seu sistema, rode o seguinte comando:

$ depmod -V

Ferramentas Específicas para Sistemas de Arquivos

Uma grande gama de ferramentas específicas para certos sistemas de arquivos são necessárias para criar, formatar, configurar e consertar partições de discos. O pacote util-linux tem algumas dessas ferramentas, mas alguns dos sistemas de arquivos mais populares têm pacotes separados que contém os programas necessários.

Ext2/Ext3/Ext4

Os sistemas de arquivos Ext3 e o experimental Ext4 são atualizações do Ext2 e podem ser gerenciados com a mesma ferramenta. Qualquer versão recente de uma ferramenta para o Ext2 também consegue funcionar com os outros dois sistemas de arquivos.

Para trabalhar com qual um desses sistemas de arquivos, você deve ter o pacote e2fsprogs. Se você deseja baixar e instalar esse pacote você mesmo, você pode encontrá-lo em http://e2fsprogs.sourceforge.net.

Para a versão 2.6.18 do kernel, a versão 1.29 do e2fsprogs é a mais antiga a funcionar corretamente com o kernel. É altamente recomendável que você use a versão mais nova para aproveitar as vantagens das novas funções dos sistemas de arquivos Ext3 e Ext4.

Para ver qual versão do e2fsprogs você tem instalado no seu sistema, rode o seguinte comando:

$ tune2fs

JFS

Para usar o sistema de arquivos da IBM, o JFS, você deve ter o pacote ifsutils. Se você deseja baixar e instalar o pacote você mesmo, você pode encontrá-lo em http://jfs.sourceforge.net.

Para a versão 2.6.18 do kernel, a versão 1.1.3 do ifsutils é a mais antiga a funcionar corretamente com o kernel. Para ver qual versão do ifsutils você tem no seu sistema, rode o seguinte comando:

$ fsck.jfs -V

ReiserFS

Para usar o sistema de arquivos ReiserFS, você deve ter o pacote reiserfsprogs. Se você deseja baixar e instalar esse pacote você mesmo, você pode encontrá-lo em http://www.namesys.com/download.html.

Para a versão 2.6.18 do kernel, a versão 3.6.3 do reiserfsprogs é a mais antiga a funcionar corretamente com o kernel. Para ver qual versão do reiserfsprogs você tem no sistema, rode o seguinte comando:

$ reiserfsck -V

XFS

Para usar o sistema de arquivos XFS da SGI, você deve ter o pacote xfsprogs. Se você deseja baixar e instalar esse pacote você mesmo, você pode encontrá-lo em http://oss.sgi.com/projects/xfs.

Para a versão 2.6.18 do kernel, a versão 2.6.0 do xfsprogs é a mais antiga a funcionar corretamente com o kernel. Para ver qual versão do xfsprogs você tem instalada no sistema, rode o seguinte comando:

$ xfs_db -V

Quotas

Para usar a funcionalidade quotas do kernel, você deve ter o pacote quota-tools*. Esse pacote inclui programas que lhe permitem configurar quotas para o usuários, fornece estatísticas sobre a quantidade de quota que está sendo utilizada por usuários diferentes e avisa quando as pessoas ficam muito próximas de atingir a quota disponível do sistema de arquivos.

Se você deseja baixar e instalar esse pacote você mesmo, você pode encontrá-lo em http://sourceforge.net/projects/linuxquota.

Para a versão 2.6.18 do kernel, a versão 3.09 do quota-tools é a mais antiga a funcionar corretamente com o kernel. Para ver qual versão do quota-tools você tem em seu sistema, rode o comando seguinte:

$ quota -V

*: Algumas distribuições, particularmente o Debian, chamam esse pacote de quota em vez de quota-tools.

NFS

Para usar o sistema de arquivos NFS, você deve ter o pacote nfs-utils*. Esse pacote inclui programas que lhe permitem montar partições NFS como um cliente e rodar um servidor NFS.

Se você deseja baixar e instalar esse pacote você mesmo, você pode encontrá-lo em http://nfs.sf.net.

Para a versão 2.6.18 do kernel, a versão 1.0.5 do nfs-utils é a mais antiga a funcionar corretamente com o kernel. Para ver qual versão do nfs-utils você tem em seu sistema, rode o seguinte comando:

$ showmount --version

*: Algumas distribuições, particularmente o Debian, chamam esse pacote de nfs-common em vez de nfs-utils.

Outras Ferramentas

Existem vários outros programas importantes que estão estreitamente ligados à versão do kernel. Esses programas normalmente não são necessários para que o kernel funcione corretamente, mas eles habilitam o acesso a diferentes tipos hardware e funções.

udev

O udev é um programa que habilita o Linux forneça um sistema de nomeação de dispositivos persistente no diretório /dev. Ele também fornece um /dev dinâmico, parecido com o antigo (e agora removido) sistema de arquivos devfs. Quase todas as distribuições Linux utilizam o udev para gerenciar o diretório /dev, então ele é necessário para iniciar a máquina corretamente.

Infelizmente, o udev depende da estrutura do /sys, que é conhecido por mudar de tempos em tempos com as versões do kernel. Algumas dessas mudanças no passado foram conhecidas por quebrar o udev, então a sua máquina não irá iniciar corretamente. Se você tem a última versão do udev recomendada para o eu kernel e está tendo problemas no funcionamento, por favor comunique os desenvolvedores do udev na lista de email disponível em linux-hotplug-devel@lists.sourceforge.net.

É altamente recomendado que você usa a versão do udev que vem com a sua distribuição Linux, já que ele está altamente ligado ao processo de boot da distribuição. Mas se você deseja atualizar o udev por sua conta e risco, você pode encontrá-lo em http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html.

Para a versão 2.6.18 do kernel, a versão 081 do udev é a mais antiga a funcionar corretamente com o kernel. É recomendado que você use a última versão do udev, afinal ele funcionará melhor com os kernels mais novos, devido à mudanças de como o udev e o kernel se comunicam.

Para ver qual a versão do udev que você tem instalada no seu sistema, rode o seguinte comando:

$ udevinfo -V

Ferramentas de Processos

O pacote procps inclui as ferramentas comumente usadas ps e top, como também muitas outras ferramentas úteis para gerenciar e monitoras processos que estão rodando no sistema.

Se você deseja baixe e instalar esse pacote por você mesmo, você pode encontrá-lo em http://procps.sourceforge.net
.

Para a versão 2.6.18 do kernel, a versão 3.2.0 do procps é a mais antiga a funcionar corretamente. Para ver qual é a versão do procps que está instalada no seu sistema, rode o seguinte comando:

$ ps --version

Ferramentas PCMCIA

Para utitizar dispositivos PCMCIA corretamente com o Linux, um programa que ajuda o userspace deve ser utilizado para configurar os dispositivos. Para versões antigas do kernel, esse programa era chamado de pcmcia-ss, mas foi substituído por um sistema muito mais simples chamado pcmciautils. Se você deseja utilizar dispositivos PCMCIA, você deve ter esse pacote instalado para que eles funcionem corretamente.

Se você deseja baixar e instalar esse pacote você mesmo, você pode encontrá-lo em ftp://ftp.kernel.org/pub/linux/utils/kernel/pcmcia.

Para a versão 2.6.18 do kernel, a versão 004 do pcmciautils é a mais antiga a funcionar corretamente com o kernel. Mas a versão mais recente é recomendada para tirar vantagem das novas funções no subsistema PCMCIA, como o carregamento automático do driver quando um novo dispositivo é encontrado.

Para ver qual é a versão do pcmciautils que você tem instalada em seu sistema, rode seguinte comando:

$ pccardctl -V

*---*---*---*---*---*---*---*---*---*---*

PDF em inglês - Chapter 2: Requirements for Building and Using the Kernel

*---*---*---*---*---*---*---*---*---*---*

Qualquer correção, crítica & derivados, nos comentários por favor. Agradecido.

Kernel Linux em Poucas Palavras – Parte 1

Se tiver alguma dúvida, consulte os PDFs em inglês disponibilizados no fim do post.

*---*---*---*---*---*---*---*---*---*---*

Parte I - Compilando o Kernel

Essa parte do livro mostra como baixar, compilar e instalar o kernel. Na maior parte é um guia passo-a-passo.

Capítulo 1, Introdução
Capítulo 2, Requisitos para Compilar e Utilizar o Kernel
Capítulo 3, Obtendo o Kernel Linux
Capítulo 4, Configurando e Compilando
Capítulo 5, Instalando e Inicializando a Partir de um Kernel
Capítulo 6, Atualizando um Kernel

1. Introdução

Apesar da sua grande base de código (cerca de sete milhões de linhas de código), o kernel Linux é um dos sistemas operacionais mais flexíveis já criados. Ele pode ser modificado para uma grande gama de sistemas diferentes, rodando em tudo, desde helicóptero controlado por rádio, passando por telefone celular até o maior supercomputador do planeta. Customizando o kernel para o seu uso específico, é possível criar algo que seja, ao mesmo tempo, mais pequeno e rápido do que o kernel fornecido pelas maiorias das distribuições Linux. Esse livro vai abranger a compilação e instalação de um kernel personalizado e fornecer algumas dicas sobre como habilitar opções específicas que você provavelmente deseja usar em diferentes situações.

Nenhuma distribuição Linux fornece o kernel exato que a maioria dos usuário querem. Distribuições modernas ficaram muito complacentes, compilando o suporte para todos os dispositivos conhecidos, para som e até economia de energia. Mas você, provavelmente, tem necessidades diferentes da maioria dos usuários (e todas as distribuições tentam abranger a necessidade da maioria). Você pode ter um hardware diferente. E quando um novo kernel é lançado, você pode querer começar a usá-lo sem esperar que a distribuição o disponibilize.

Por uma série de razões, durante o uso no dia-a-dia com o Linux, você deseja compilar um kernel ou ajustar os parâmetros que você está executando. Esse livro lhe dá a informação que você necessita para compreender o kernel do ponto de vista do usuário e para fazer ma mudanças mais comuns.

Também existem bons motivos para remover funcionalidades do kernel, particularmente se você está rodando-o num sistema embarcado ou num sistema pequeno.

Quando se fazer ajustes, é útil entender as entranhas do comportamento do kernel. Isso está além do escopo desse livro, exceto por breves sumários que aparecerão em certas opções. O apêndice B inclui referência para outros livros e materiais que podem lhe dar um maior background.

Utilizando Esse Livro

Não configure ou compile o seu kernel com as permissões de superusuário habilitadas!

Esse aviso é a coisa mais importante para se lembrar enquanto seguir os passos desse livro. Tudo nesse livro – baixar o código fonte do kernel, descompactá-lo, configurar o kernel e compilá-lo – deverá ser feito como um usuário normal da máquina. Somente dois ou três comandos que são necessários para instalar um novo kernel deverão ser feitos como superusuário (root).

No passado, houve bugs no processo de compilação do kernel, criando alguns arquivos especiais no diretório /dev para serem deletados se o usuário tinha permissões de superusuário enquanto compilava o kernel Linux. Também há alguns problemas que podem ocorrer facilmente quando descomprimir o kernel Linux com direitos de superusuário, já que alguns dos arquivos no pacote da fonte do kernel terminarão sem as permissões corretas e, mais tarde, causarão erros na compilação.

O código fonte do kernel jamais deverá ser colocado no diretório /usr/src/linux, já que esse é o local do kernel que as bibliotecas do sistema foram compiladas anteriormente, não o seu kernel customizado. Não faça qualquer desenvolvimento com o kernel sob o diretório /usr/src, somente o faça num diretório de usuário local onde nada de ruim possa acontecer com o sistema.

*---*---*---*---*---*---*---*---*---*---*

PDF em inglês - Part I: Building the Kernel
PDF em inglês - Chapter 1: Introduction

*---*---*---*---*---*---*---*---*---*---*

A partir de agora começa a parte que interessa. Até agora, admito, foi só secação de gelo.

Kernel Linux em Poucas Palavras – Parte 0

Esse é um novo projeto do blog. Como a compilação e o modo como o kernel funciona interessa não só os usuários novatos – e curiosos – como também os mais avançados, essa é uma boa oportunidade para mostrar como a compilação do kernel funciona com mais detalhes. Traduzirei, até onde sou capaz, o guia “Kernel Linux em Poucas Palavras” (Linux Kernel in a Nutshell, Greg Kroah-Hartman) em doses homeopáticas – tanto para os leitores quanto pra mim. Espero que consiga chegar até o final com uma qualidade satisfatória. Farei de cada capítulo uma parte no blog para não ficar muito pesado e modorrento. Vamos ao que interessa.

Kernel Linux em Poucas Palavras – Parte 0 – Prefácio

Quando o assunto desse livro foi me apresentado pela primeira vez, não dei muita atenção como se isso já estivesse abordado pela completa documentação sobre o kernel Linux. Certamente alguém já escreveu sobre as necessidades básicas a fim de compilar, instalar e customizar o kernel Linux, afinal essa me parece uma tarefa simples.
Após garimpar em diferentes HOWTOs e pelo diretório de documentação do kernel Linux, cheguei à conclusão de que não havia um lugar onde toda essa informação pudesse ser encontrada. Poderia ser catada por referência alguns arquivos aqui, outros sites antigos acolá, mas não era aceitável para ninguém que não sabia exatamente o que estava procurando no primeiro momento.
Portanto, esse livro foi criado com o objetivo de consolidar toda a informação existente que está dispersa na Internet sobre como compilar o kernel Linux, assim como adicionar muitas informações  novas e úteis que não foram escritas em nenhum lugar mas foram aprendidas pelo método tentativa/erros ao longo dos meus anos desenvolvendo o kernel.
Meu objetivo secreto com esse livro é trazer mais pessoas para o desenvolvimento do kernel Linux. O ato de compilar um kernel customizado para a sua máquina é uma das tarefas básicas para se tornar um desenvolvedor do kernel Linux. Quanto mais pessoas tentarem e perceberem que não existe mágica por trás de todo o processo do kernel Linux, mais pessoas estarão dispostas a se juntar e ajudar a fazer do kernel o melhor que ele pode ser.

Para Quem Esse Livro é Indicado

Esse livro é destinado a abranger tudo o que for necessário para saber a fim de compilar, customizar e instalar o kernel Linux apropriadamente. Nenhum experiência com programação é necessária para entender e usar esse livro.
Alguma familiaridade com a utilização do Linux e algum conhecimento de linha de comandos é esperado do leitor.
Esse livro não é destinado aos aspectos de programação do kernel Linux; existem vários outros bons livros listados na Bibliografia que já façam desse assunto.

Como o Livro está Organizado

Esse livro está organizado em quatro partes.

Parte I, Compilando o Kernel é constituído do Capítulo 1 ao 6 que abrage tudo o que você precisa saber sobre como obter, compilar, instalar e atualizar o kernel Linux, mais ou menos no estilo passo-a-passo.

Capítulo 1, Introdução
Esse capítulo explica quando e porque você desejará compilar o kernel.

Capítulo 2, Requisitos para Compilar e Utilizar o Kernel
Esse capítulo abrange os diferentes programas e ferramentas que são necessárias para compilar o kernel apropriadamente. Ele também abrange vários outros programas que estão estreitamente ligados ao kernel, como decidir a versão necessária dos programas e onde achá-los.

Capítulo 3, Obtendo o Kernel Linux
Esse capítulo discute como as diferentes versões do kernel se relacionam uma com as outras, onde obter o código fonte do kernel Linux e como baixá-lo da maneira correta.

Capítulo 4, Configurando e Compilando
Esse capítulo explica como configurar e compilar apropriadamente o kernel Linux.

Capítulo 5, Instalando e Inicializando a Partir de um Kernel
Esse capítulo mostra como instalar o kernel que foi compilado apropriadamente e, então, inicializar através desse kernel.

Capítulo 6, Atualizando um Kernel
Esse capitulo explica como atualizar um kernel que foi compilado anteriormente para uma nova versão sem ter que começar do zero.

Parte II, Principais Personalizações é constituído do capítulo 7 e 8, no qual descreve como configurar apropriadamente o kernel baseado no hardware prsente no sistema e fornece várias “receitas” diferentes para configurações comuns.

Catítulo 7, Personalizando um Kernel
Esse capítulo discute como personalizar o kernel para o hardware que está presente no sistema. Além disso, uma variedade de formas para determinar quais opções devem ser selecionadas e alguns scripts simples para ajudar na tarefa.

Capítulo 8, Receitas de Configuração para o Kernel
Esse capítulo explica como configurar o kernel para uma variedade de situações comuns.

Parte III, Referências do Kernel é constituido do capítulo 9 ao 11. Esses capítulos fornecem referências para as diferentes opções de linha de comando do kernel, para as opções de compilação do kernel e seleciona algumas das diferentes opções de configuração do kernel.

Capítulo 9, Referência para Parâmetros em Linha de Comando do Boot do Kernel
Esse capítulo detalhs todas as diferebtes opções em linha de comando que podem ser passadas ao kernel e o que as diferentes opções fazem.

Capítulo 10, Referência de Linha de Comando na Complilação do Kernel
Esse capítulo descreve as diferentes opções em linha de comando que estão disponíveis quando compilar o kernel e como usá-las.

Capítulo 11, Referência de Opções de Configuração do Kernel
Esse capítulo foca em algumas das mais populares e impotantes opções de configuração do kernel.

Parte IV, Informação Adicional

Apêndice A, Ferramentas Úteis
Esse capítulo introduz várias ferramentas muito boas e úteis que todos que desejam acompanhar a última versão do kernel Linux deveriam usar.

Apêndice B, Bibliografia
Esse capítulo fornece uma lista de referências úteis que você pode usar para localizar mais informações sobre compilar o seu kernel Linux.

Versão Online e Licença

Esse livro está disponível livremente sob a licença Creative Commons “Attribution- ShareAlike”, Versão 2.5. Essa licença pode ser vista em sua totalidade em http:// reativecommons.org/licenses/by-sa/2.5/. O livro completo também está disponível online em http://www.kroah.com/lkn.

Convenções Usadas Nesse Livro

Esse livro utiliza as seguintes convenções tipográficas:

Itálico – Indica programas, ferramentas, comandos e opções de comandos, pacotes de distribuição, arquivos, diretórios, nome de usuários, hostnames. Também indica nomenclatura que não usamos anteriormente e palavras enfatizadas.

Largura Constante – Indica valores usados para a configuração do kernel, também para alguns termos especiais como nomes de dispositivos. Também é usado para mostrar o resultado de comandos e o conteúdo de arquivos de texto e de programas.

Largura Constante em Negrito – Usada em exemplos para indicar comandos ou outro texto que deverá ser digitado literalmente pelo usuário.

Largura Constante em Itálico – Indica texto que você deverá substituir com os seus próprios valores; por exemplo, o seu próprio nome de usuário e senha. Quando isso aparecer como parte do texto que você deverá digitar, isso é mostrado como Largura Constante em Negrito Itálico.

#, $ - Usado em alguns exemplos como shell de prompt root (#) ou como prompt de usuário ($) sob o shell bash ou Bourne.


   - Indica uma dica, sugestão ou nota em geral.

 - Indica um aviso ou cuidado.

Usando Shell Scripts

Esse livro está aqui para ajudar você a fazer o seu trabalho. Em geral, você pode usar os shell scripts desse livro nos seus próprios scripts e documentação. Você não precisa nos comunicar para parmissão. Os principais scripts podem ser baixados do website do livro na O'Reilly Media,  http://www.oreilly.com/catalog/9780596100797. Nós agradecemos, não não exigimos, atribuição. Uma atribuição nortmalmente inclui título, autor, publicador e ISBN. Por exemplo: “Linux Kernel in a Nutshell by  Greg Kroah-Hartman. Copyright 2007 O’Reilly Media, Inc., 978-0-596-10079-7.”. Se você acha que o seu código não se encaixa no uso ou permissão acima, sinta-se à vontade em nos comunicar em:

permissions@oreilly.com.

Como Nos Contactar

Nós testamos e verificamos todas as informações contidas nesse livro ao máximo das nossas habilidades, mas você pode achar que funções mudaram (ou até mesmo que nós cometemos erros!). Por favor nos informe sobre qualquer erro que você encontrar, e sugestões para futuras edições, escrevendo para:

     O’Reilly Media, Inc.
     1005 Gravenstein Highway North
     Sebastopol, CA 95472
     800-998-9938 (nos Estados Unidoso ou Canadá)
     707-829-0515 (internacional/local)
     707-829-0104 (fax) 

Você também pode nos enviar mensagens eletrônicas. Para ser incluído em listas de email ou requisitar um catálogo, envie um email para:

info@oreilly.com

Para perguntar sobre questões técnicas ou comentar sobre o livro, envie um email para:

bookquestions@oreilly.com

Nós temos um site para o livro, onde listaremos exemplos, erratas e qualquer plano para futuras edições. Você pode acessar esse página em:

http://www.oreilly.com/catalog/9780596100797

Agradecimentos

Primeiramente, agradeço à minha maravilhosa esposa Shannon e meus lindos filhos Madeline e Griffin por sua compreenção e paciência enquanto trabalhei nesse livro. Sem seus incentivos e suporte, esse livro jamais estaria completo. Agradecimentos especiais à Shannon por me introduzir ao desenvolvimento do kernel Linux em primeiro lugar. Sem os esforços dela, eu ainda estaria fazendo algum trabalho estranho de programação ambarcada e jamais teria descoberto essa maravilhosa comunidade na qual estou trabalhando.

Meu editor, Andy Oram, por ser a força motriz por trás desse livro, transformando o livro em algo que seja, ao mesmo tempo, de leitura agradável e informativo. Suas habilidades de edição e paciência enquanto os prazos voavam foram determinantes na criação e finalização desse livro.

Também um grande obrigado vai para o editor original desse livro, David Brickner, por me dar a chance de trabalhar nesse projeto e acreditar que eu poderia completá-lo, apesar da primeira versão ter cerca de 1.000 páginas.

Os revisores técnicos desse livro foram maravilhosos, corrigindo os vários erros e indicando as omissões que precisavam ser preenchidas. Os revisores foram (em ordem alfabética)hristian Benvenuti, Christian Morgner,  Golden G. Richard III, Jean Delvare, Jerry Cooperstein, Michael Boerner, Rik van  Riel, and Robert Day. Qualquer problema pendente é devido à mim e não às excelentes habilidades deles.

Um agradecimento especial a Randy Dunlap por verificar os parâmetros de boot do kernel com um pente fino e apontar problemas naquele capítulo. Também para Kay Sievers, que me ajudou imensamente com todo o capítulo sobre a customização do kernel e que fornecer o script no final desse mesmo capítulo. Sem sua ajuda e conhecimento, aquele capítulo jamais seria possível.

E um último agradecimento especial para a minha professora de inglês da 6ª série, Sra. Gruber, por me ensinar que escrever era algo que era possível fazer e por me mostrar o prazer ao fazê-lo. Sem esse início, nada disso seria possível.

*---*---*---*---*---*---*---*---*---*---*

Aguarde os próximos capítulos..

Anunciado o mascote do Ubuntu 9.10

Karmic Koala. A parte mais impactante do anúncio é esse:

O desktop terá toques de designers por todo ele - agora estamos dando inicio a um sério esforço em direção de uma nova aparência. O marrom nos foi muito útil mas o Koala está considerando novas opções.

Fonte: Ubuntu.com

Plantão Médico - Versão Linux

Se lembram daquela série Plantão Médico??? E se a série fosse transportada para o mundo Linux, como seria?? Veja abaixo a resposta:

O Blog está em marcha lenta. Sabe como é; também sou filho de Deus.

EXT4 será padrão no Fedora 11

Se os planos não mudarem, o próximo release do Fedora, a versão 11, tratá como padrão para o sistema de arquivos o novato EXT4. Essa decisão foi feita pelo FESCo (Fedora Engineering Steering Committee).

Com essa decisão o Fedora 11, que deverá sair em maio, passará à frente do Ubuntu 9.04 - Jaunty Jackalope - que deverá sair em abril.

Além do suporte ao ETX4, o Fedora 11 também trará na arvore do kernel o Btrfs, um novíssmo e turbinado sistema de arquivo. As opções aumentam e quem escolhe é você.

Rússia pretende desenvolver uma distribuição nacional

De acordo com o site CNews Russia, o governo Russo pretende desenvolver uma distribuição nacional própria para diminuir a dependência de "licenças de software estrangeiros". O país se focará no Linux e espera ter uma impacto global.

Fedora 10: A Comunidade do Futuro

É um degrau a mais que o blog sobe. Primeiro vídeo traduzido, é o começo um conteúdo mais multimídia além de textos. Espero que gostem.

Para começar, um vídeo lançado pela RedHat Magazine com um bate-papo entre Paul Frields, líder do ProjetoFedora, e Greg DeKoenigsberg, guru da comunidade RedHat sobre o Fedora 10 e suas inovações e etc.

Qualquer correção manda nos comentários!!

Entrevista com Enrico Zini, desenvolvedor do Debian

O site Free Software Foundation Europe fez uma entrevista com um de seus membros, Enrico Zini. Enrico também é um desenvolvedor do Debian e se ocupa com muitas outras coisas. Segue abaixo a tradução. Para correções, manda bala nos comentários.

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

Enrico Zini é um Parceiro da FSFE há muito tempo e proeminente desenvolvedor do Debian. Ele esteve envolvido em muitos projetos diferentes relacionados com o Software Livre e está profundamente preocupado com questões sociais. Tive uma boa conversa com Enrico e perguntei-lhe sobre algumas de suas causas favoritas.

Stian Rødven Eide: Você é um colaborador antigo do projeto Debian, especialmente a respeito de pacotes. Você pode nos dizer, brevemente, qual é a sua principal responsabilidade no projeto Debian?

Enrico Zini: Eu cuido principalmente dos Debtags, um novo sistema de organização para pacotes Debian. Essa é minha principal responsabilidade oficialmente.

SRE: Vários dos seus projetos em Software Livre lidam com dados meteorológicos. O uso do Software Livre em instituições meteorológicas é elevado?

EZ: As instituições meteorológicas são diversificadas, variando de pequenas estações regionais a estações nacionais e militares, ou até instituições internacionais. A escolha do software depende de muitos fatores, muitas vezes até de fatores políticos. Dito isto, definitivamente vejo uma crescimento do Software Livre com várias estações começando a publicar seus próprios códigos como Software livre. Um dos exemplos mais notáveis é nada menos que a ECMWF, que lançou recentemente a maioria de seus software sob a GPLv3 (note que mesmo quando alguns links mencionam a necessidade de uma taxa de manipulação de £100, na maioria dos casos, o software que você receberá está licenciado sob uma licença livre).

Os Estados Unidos estão agindo melhor, graças às melhores leis de acesso a informações que obrigam a publicação muitas informações governamentais como domínio público, e se você acessar o NOAA (a agência americana equivalente à ECMWF ), você será capaz de baixar tanto o código-fonte quando as informações - freqüentemente publicadas como domínio público. Também por causa disso, os Estados Unidos tendem a usar formatos livres com o HDF5 ou o NetCDF; enquanto na União Européia, por exemplo, a fim de decodificar as imagens do satélite Meteosat, você ainda necessita de uma sórdida biblioteca de descompressão de ondas curtas que é grátis para baixar, até mesmo o código-fonte, então você pode recompilar no seu sistema, mas ela tem uma desagradável licença e está pesadamente sobrecarregada de patentes.

Espero que as recentes mudanças nas políticas de distribuição da ECMWF sejam o primeiro dos vários passos na direção correta e que estamos indo na direção de um sistema onde os cidadãos da União Européia possam acessar as informações que no momento elas precisam pagar para adquirir.

SRE: Você vem apoiando expressamente a presença das mulheres no Projeto Debian. Você sente que a situação das mulheres no Software Livre melhorou durante os últimos anos?

EZ: Creio que há, ao menos em alguns grupos, uma melhor atitude: é bastante difícil soltar uma piada sexista em alguma das listas principais de email do Debian, e acho que é uma coisa boa. Muito mais importante do que isso é que enquanto as mulheres sempre foram parte das inovações na computação de um jeito ou de outro, agora, mesmo nos projetos em Software Livre, vemos as mulheres assumindo a liderança como, no caso do Debian, entre os desenvolvedores do KDE no Debian ou entre a equipe Debian Game. Isso é muito importante porque uma mulher numa sociedade machista como, digamos, a Itália, pode ver que sim, isso pode ser feito e pode, portanto, perseguir seus próprios interesses sem acreditar que ela é "louca" ou em qualquer outra coisa que a sociedade machista gostaria que ela acreditasse.

Dito isso, há muito trabalho a se fazer. Alguns grupos de alto nível estão fazendo direito e podem criar um exemplo importante, mas ainda existem muitos grupos pequenos, mais locais, onde a situação está terrível.

SRE: O que você acha que podemos fazer para tornar o envolvimento em projetos de Software Livre mais atrativo para as mulheres?

EZ: Digamos que, por exemplo, estou num canal italiano do Debian no IRC e as pessoas estão conversando com piadas sexistas, aí eu digo "Parem com isso, seus idiotas, o que vocês acham que as pessoas do DebianKDE diriam lendo o que vocês acabaram de escrever?"

Entretanto, acho que o sexismo é um dos muitos tipos de discriminação que podem existir. Definitivamente, é uma discriminação claramente visível. Mas alguns projetos podem ter, talvez não intencionalmente, discriminação contra pessoas que não estão sempre no IRC, ou contra pessoas que não são positivas o suficiente nas listas de email, ou contra pessoas com internet lenta, ou contra colaboradores não técnicos. Às vezes até mesmo pessoas em fusos-horários diferentes podem ser discriminadas. Acredito que deveríamos evoluir na direção de uma atitude que nos permita fazer dos projetos em Software Livre algo mais atrativos para as mulheres, e também para todos que possam ser um colaborador valioso.

SRE: Você é co-autor de um estudo amplamente baseado em experiências da Keynes High School, em Bologna, que adotou cedo o Software Livre. Você, inicialmente, era um estudante na escola e e acabou se envolvendo como um professor ocasional, pesquisador e apoiador do sistema. Apesar da resistência inicial, houve grandes dificuldades na implementação do Software Livre na escola?

EZ: Até agora, as únicas dificuldades que sobraram são os professores. Alguns estão motivados para usar Software Livre e fazem coisas ótimas. Mas a maioria dos professores vem aprendendo a usar o Microsoft Office e temem que se eles usarem outro ambiente, seu processo de aprendizagem será inútil (o que é falso), ou que os estudantes terão mais confiança do que o professor a não ser que os professores usem a suíte que eles conhecem melhor (o que também é falso; sempre haverá alunos mais confiantes do que os professores com QUALQUER suite de software). Portanto, esses receios de não ser adequado para ensinar acabam transformando o "software diferente" num bode expiatório. A escola teve de manter um laboratório Microsoft Office extra - e custoso - para resolver essa situação.

Mas a experiência na Keynes não acabou. Por exemplo, recentemente deram uma nova vida ao laboratórios antigos com um pequeno investimento graças às configurações LTSP, e quando outras escolas com pequenos orçamentos viram isso, elas pediram aos técnicos da Keynes para ajudá-las a fazer o mesmo. E agora temos várias escolas primárias e secundárias espalhadas na zona rural de Bologna que estão rodando Software Livre e estão muito felizes com seus antigos laboratórios de máquinas Pentium II que se tornaram estações de trabalho modernas com um mero investimento de 4 ou 5 mil euros num novo servidor LTSP. Isso realmente mostra as promessas do Software Livre acontecendo de verdade: Uma vez que você pega pessoas habilidosas e coloque-as no controle da tecnologia, os problemas se resolvem.

SRE: Qual é o seu conselho para professores e administradores de sistemas que querem expandir o uso do Software Livre em escolas e universidades?

EZ: Meu maior conselho é achar outros professores e administradores de sistemas que já fizeram isso e manter contato. O que mais ajuda é saber que você não está sozinho. Você pode compartilhar os seus problemas e especialmente as soluções. Fazer uma lista de emails privada para anúncios e combinar com todos para postar todos os problemas que precisam resolver, todas as coisas legais que conseguiram fazer. Assim, se outros tiverem um problema parecido, saberão a quem perguntar.Digo privada pois algumas vezes para fazer coisas legais, você precisa pensar maliciosamente, e você não quer que as pessoas não digam que elas fizeram algo bom porque temem que isso seja indexado pelo Google. Ou ainda melhor: se as pessoas têm preguiça para escrever, organizar reuniões regulares com outros professores ou administradores que têm a mesma idéia com cerveja, vinho ou qualquer outra coisa parece uma boa idéia.

SRE: Você participou de várias edições do European Social Forum e até iniciou o Bologna Free Software Forum. Você vê uma ligação entre esse tipo de espaço social e o modo como as comunidades do Software Livre funcionam em geral?

EZ: Certamente vejo uma ligação porque ambas comunidades quebraram barreiras. No Debian, temos pessoas que trabalham em corporações, talvez algumas em ambientes militares, temos ativistas políticos, anarquistas e temos pessoas profundamente religiosas. Todas essas pessoas trabalham juntas no Debian, talvez jamais se dariam bem na vida real. Mas isso mostra que já existe espaço para quem vem dos fóruns sociais nas comunidades de Software Livre e, por experiência própria, esse espaço não está vazio, ou seja, já existe uma sobrecarga. Quem diria que alguém na Equipe de Segurança no Debian não teria adquirido conhecimento por cuidar da segurança de servidores de email usados por ativistas políticos, por exemplo?

Um grande problema que vejo no momento, ao menos em alguns grupos que conheço na Itália, é o problema de criar um melhor entendimento da Internet em ambientes de fóruns sociais. As pessoas de um exemplo imaginário "Liga do Fazendeiros Orgânicos", teriam trabalho suficiente para fazer do que ter que aprender a separaremails normais de spam ou phishing , por exemplo, ou planejar a migração para Software Livre. Ativistas costumam viver ocupados ao limite de enlouquecer e isso normalmente prejudica a adoção de novas tecnologias ou do Software Livre ou de novas técnicas de comunicação - o que é uma vergonha.

SRE: Você acha que a mentalidade e métodos do Software Livre podem nos ensinar sobre interação social e política?

EZ: Acho que ele nos ensina a manter em mente os nossos objetivos. Eventualmente, o software resolve um problema, mas se você apenas passar seu tempo fazendo algo complexo que não funcione, você não se torna um desenvolvedor de Software Livre. Interações sociais e políticas têm, por experiência própria, uma tendência de criar sistemas que se tornam complexos, onde as discussões sobre uma questão social eventualmente acabam em discussões sobre o grupo em si, ou se tornam nada mais do que discussões, discussões e não se chega a lugar algum. Assim como no Debian nós temos ativistas e pessoas que trabalham em corporações trabalhando junto, no protesto de Genoa, em 2001, chamei tanto grupos de anarquistas quanto escoteiros para fazer o protesto porque ambos queriam a mesma coisa. Gostaria de ver isso de novo. Essa cooperação ainda está viva no mundo do Software Livre e talvez isso sirva de inspiração.

SRE: Um dos projetos decorrentes do Bologna Free Software Forum é o Comodino, que preconiza a critica ao consumo de produtos de TI. Ele envolve pensar em termos de sustentabilidade e ética quando adquirir produtos de TI, o que, obviamente, é um forte argumento para escolher o Software Livre. Como o projeto está indo?

EZ: O projeto ainda está vivo e está cumprindo o seu papel. Provavelmente, apenas obtivemos uma mudança cultural limitada a respeito da tecnologia entre nossos usuários, principalmente porque a manutenção do servidor tem nos mantido ocupados o suficiente para sermos capazes de participar de outras iniciativas. Entretanto, estamos hospedando 50 websites e incontáveis listas de email, dando a vários grupos uma chance para ter presença online, sem propagandas em suas listas de emails , com acesso aos arquivos da lista e todos esses benefícios indescritíveis de ter um sistema gerenciado por pessoas que gostariam de ter, como você, sucesso em seu objetivo social ao invés apenas pegar o seu dinheiro e minimizar os problemas. Nós também estamos fazendo a transmissão de uma rádio real e algumas rádios online.

SRE: Portanto, o objetivo primário é fornecer serviços para projetos sociais?

EZ: Sim. No fim das contas, é um servidor Xen com DNS, Postfix, Sympa para listas de emails e um LAMP DomU hospedando vários pequenos clones PostNuke, ou qualquer outro PHP horrível que as pessoas gostam de criar hoje em dia. Mas, humildemente, ele funciona para muitos grupos pequenos.

Fonte: ciaran@Fellowship of FSFE

O computador doméstico em 2004 (como imaginado em 1954)

Essa é sensacional. Vendo meus feeds, encontro essa pérola:

[Clique na imagem para ampliar]

Detalhe para a legenda:

Cientistas da RAND Corporations criaram esse modelo para ilustrar como um "computador doméstico" se pareceria no ano de 2004. Entretanto, a tecnologia necessária não será economicamente viável para a maioria dos lares. Além disso, os cientistas admitem de imediato que o computador precisará de tecnologias ainda não inventadas para funcionar, porém, com o progresso científico dos próximos 50 anos, espera-se resolver esses problemas. Com uma interface com um teleimpressor e linguagem Fortran, o computador será de fácil utilização.

O que acharam hein? Precisos, não? Acho que eles hesitaram entre Fortran e COBOL!! É o sonho de todo casemodder!!! Aliás, vou ali trocar a fita da impressora matricial e já volto!!!

Para quem não sabe o que é um "teleimpressor":

Teleimpressor s.m. Aparelho telegráfico, adotado sobretudo em grandes jornais, cujo transmissor de assemelha a uma máquina de escrever comum, e cujo receptor imprime, em lugar de sinais, as letras que formam as mensagens escritas, teletipo. Te.le.im.pres.sor

Juro que tentei achar um sinônimo um pouco mais moderno mas nenhum ficaria na atmosfera da imagem.

Silverlight: lá vem o negão...

Se lembram daquela antiga música (música??) "lá vem o negão"? Sobre um negão que passava o rodo, não importava quem, o importante era ........ marcar presença. Pois bem, o Silverlight é o novo negão. Jogando nas onze, fungando no cangote de todo mundo.

O mais novo acordo para que o Silverlight seja divulgado, depois de firmar acordo com várias transmissoras da olimpíada de Beijin para transmissão on-line usando um player baseado no Silverlight, em detrimento de um Flash player, é a transmissão oficial da posse de Barack Hussein Obama à presidência da República dos Estados Unidos da América. Um evento histórico com um potencial de marketing fantástico.

Enquanto isso, na sala de justiça, a Adobe fica comendo mosca, achando que a sua maciça liderança no mercado está assegurada. Porém, quando o assunto é liderança no mercado, a Microsoft já tem doutorado.

É a água batendo na bunda da Adobe.

A galera do "apenas funcione"

Um das coisas que tenho visto cada vez mais ultimamente é uma atitude "eu quero apenas que funcione". Estranhamente, essa não é uma atitude nova, mas conforme nos expandimos em novos mercados e avançamos por novos grupos de usuários, começamos a encontrar pessoas como essas mais freqüentemente.

Parte dos motivos por trás disso é que já coletamos todos os frutos acessíveis de diferentes tipos de árvores ao longo do caminho. Nós coletamos todos (ou a maioria) os super geeks, administradores de sistemas e os power users. Mas agora, conforme começamos a pegar os consumidores diários normais, começamos a encontrar várias pessoas da galera do "apenas funcione".

Essas são, tipicamente, as pessoas que não querem pensar sobre o que estão fazendo com um computador ou qualquer coisa além de seu trabalho. Elas querem apenas apontar, clicar e que aconteça o que elas querem. Mais ou menos como os botões de apertar mentalmente dos Jetsons.

Eu vi isso não só na conferência de imprensa na da Sandisk, como também na da Samsung, Sony, Toshiba, Panasonic e nos outros grandes estandes da CES. O foco na galera do "apenas funcione" pareceu ser o centro do marketing deles. E advinha? Está funcionando.

E por que estamos reclamando quando as pessoas anseiam por sistemas que são super simplificados? No entanto, agimos como se fosse um pecado herege se alguém realmente queira que uma interface de usuário que seja dinâmica, simples e sem funcionalidades e reconfiguração expandidas. O incrível número de opções reconfiguráveis do KDE é um dos motivos pelos quais eu adoro ele, e odeio o GNOME porque esse nível de reconfiguração está ausente. Mesmo assim, estranhamente, as pessoas gostam. Então, se não se importam em perder algumas ferramentas poderosas em troca de uma maior facilidade de uso, que assim seja.

Esse é uma das coisas que levou as pessoas aos Macs por anos. Essa super simplicidade. Nós, por outro lado, como power users, eu mesmo especialmente, continuamos agarrados na mentalidade de que "deve ter funcionalidades, reconfiguração e opções poderosas". É por isso que o Ubuntu e o Mint são tão populares com os usuários normais, mas o FreeBSD, Arch e Slackware estão em alta com os usuários mais assíduos. Se você gosta das coisas simples, vá por um caminho. Se gosta das coisas mais potentes com grande quantidade de opções configuráveis, vá por outro caminho.

E antes de ser egocêntrico e chamar a galera do "apenas funcione" de idiotas, olhe para si mesmo. Você provavelmente dirige um carro, certo? Se não, apenas me acompanhe nesse exemplo. Você entra no seu carro, gira a chave, acelera e sai dirigindo. Você quer saber como as coisas funcionam sob o capô? A não ser que você goste de mecânica, a resposta geralmente é não.

Você quer que "apenas funcione", apesar dos fanáticos por mecânica espernearem porque os carros modernos "apenas funcionam" e não há mais nenhum esforço real requerido para manter o carro funcionando, além de manter o carro bem abastecido com gasolina, óleo e pneus. Ainda assim, para muitos deles, um carro super simples, especialmente aqueles que você não pode modificar, é um pecado mortal. E mesmo assim você não tem problema com isso.

Mas você vai espernear porque um outro alguém quer a mesma coisa básica, mas numa interface de um computador? Isso é um pouco hipócrita, você não acha? Só porque alguém deseja uma interface super ultra simplificada não significa que a sua "geekcidade" está subitamente ameaçada.

Exemplificando: um dos membros do meu fórum (Monty) teve a gentileza me apontar, recentemente, um erro na minha forma de pensar que surgiu a respeito de um novo netbook que estava sendo lançado. O netbook simplesmente tinha a linha de comando desabilitada, entre uma ampla gama de outras funcionalidades. Me queixei sobre isso até ele observar que, para os usuários comuns, isso não importava. Para um super geek, apenas dê a ele algumas semana e ele será capaz de reabilitar essa funcionalidade e muito mais. O mesmo tipo de coisas aconteceram com o Asus EeePC, então por que com esse não? Acredite em mim, essa foi, para mim, uma revelação de proporções épicas.

No final das contas, cada um de nós precisa de um revelação pessoal. A Asus já percebeu essa mudança nos grupos de mercado. É por isso que seus netbooks com Linux estão vendendo tão bem e os netbooks da MSI não. Bem, obviamente sem contar a interface mal projetada, claro. Mas veja o EeePC. Se lembra da interface genérica que era oferecida com ele? Se lembra como tivemos um completo ataque porque era "muito simples"? Se lembra como os geeks ao redor do mundo festejaram quando alguém descobriu como deixar no "modo avançado"?

No entanto, curiosamente, muitos dos usuários menos entendidos de computadores com os quais trabalhei amam a interface simplificada. E não é apenas no EeePC que eles querem esse tipo de interface. Por exemplo, dei, recentemente, a minha mãe um tocador de MP3 que tinha 5 botões. Sem tela, sem menus, nada. Apenas cinco botões. Ela amou de paixão.

Entretanto, quando dei a ela um dos meu tocadores de MP3 antes disso, elas simplesmente atirou na parede de frustração porque era muito difícil navegar pelas pastas. Eu não achava difícil, mas ela achava. E ela não é a única a ter problemas com tecnologias como essa.

Outro membro do meu fórum (DaveB) também contribuiu com um pequeno exemplo para esse pensamento que, acho eu, se encaixa perfeitamente. Vou compartilhar aqui nas palavras dele:

Exemplificando: minha esposa não tem interesse em computadores. Até um mês atrás nunca tinha usado um computador para nada, não estava interessada.

Recentemente, ela achou necessário usar o correio eletrônico, então configurei um laptop com o PCLinuxOS 2007 para ela. Tudo que ela queria era onde clicar. Ela não tem interesse no fato de ser Linux, como o programa é chamado, por que ela está usando Linux... nada disso.

Ela está interessada em como usar.

Simples, objetivo, ela quer apenas para trabalhar. Não se importa com o resto - e sejamos honestos, não há motivo para que ela se importe.

É uma ferramenta. Precisamos saber como funciona um microondas, um abridor de latas ou a nova tela de alta definição super fina na parede? Nós queremos conectar as coisas e usá-las. Então por que deveria ser diferente com um PC ou laptop?

Esse é um argumento que indica bem o novo tipo de usuário que estamos começando a ver no mundo Linux/FOSS. E iremos encontrar MUITAS pessoas como essas que têm o pensamento "apenas funcione" conforme expandimos nossas fronteiras em direção ao mercado comum. E se eles são o nosso mercado alvo para novo usuários, o que estamos fazendo para atraí-los?

Fonte: Steve Lake@Raiden's Realm

Sobre kernels e kerneis

Bem, ao traduzir o artigo abaixo, não pensei que uma mísera palavra geraria tamanha discussão. Essa questão sobre como pronunciar - e escrever - os termos técnicos realmente é um mato pior do que eu pensava, e quando ví, eu, um pobre diabo, estava discutindo com o editor da maior e melhor revista sobre Linux e um estudante de etimologia.

Levando-se em conta que todos que falam a língua portuguesa se referem ao núcleo do sistema Linux como "kernel", até mesmo os nossos irmãos lusitanos que tendem a preservar a língua um pouco mais que nós brasileiros, não vi motivos para não passar kernel para uma forma pluralizada em português - alguém aí se refere ao kernel com outra palavra??? Pronto. Estava feita a cagada. Conversa vai, conversa vem, decidi perguntar a alguém que não tenha dúvida sobre a questão. Contatei o Professor Paulo Hernandes - professor de lingüística, semântica, lexicologia, etc - para resolver o embaraço. Vamos à resposta:

Se você aportuguesar, deve manter o acento, já que a palavra é paroxítona terminada em "s", caso de "mísseis". A reforma não abrangeu essa situação. Se preferir a forma original, o plural será feito com simples acréscimo de "s" e a palavra deverá ser colocada entre aspas.

Resumindo o resumo, o certo é "kernels" ou kérneis. Repetindo, levando-se em conta todos usam a palavra "kernel" para se referir ao dito cujo.

O que farei?? Vou mudar para kernels no artigo. Problema resolvido (creio eu).

O retorno do Minix

A revista Linux Magazine de fevereiro publicou uma review do Minix 3 contando a história do sistema, diferenças entre o Minix e o Linux, como o sistema funciona basicamente e ainda, juntamente com a review, um artigo do autor do sistema, Andrew S. Tanenbaum, sobre o uso do computador hoje em dia e como a estrutura do Minix pode fazer a diferença levando-se em conta os objetivos dos usuários comuns. A matéria é bem longa - como eu gosto - mas vale à pena cada frase. No fim do post estão os arquivos em PDF da matéria original e da versão traduzida.

-*-*-*-*-*-*-*-*-*-*-*-*-

Kernel Inteligente
por Rüdiger Weis / Tradução: Luiz Martins

O Linux tem uma longa e tempestuosa relação com outro sistema operacional Unix-like conhecido como Minix. Adrew S. Tanenbaum, notável autor e cientista da computação, lançou a primeira versão do Minix em 1987 como uma ferramenta para ensinar estudantes sobre sistemas operacionais, e esse pequeno e bem documentado sistema rapidamente se tornou popular entre os entusiastas. Numa postagem ao grupo de notícias Minix, um ambicioso graduando finlandês, Linus Torvalds, anunciou o seu próprio sistema experimental em 1991 e contribuidores rapidamente vieram dos postos da comunidade Minix.

Mas Tanenbaum e Torvalds de imediato não se entenderam sobre questões do design. Tanenbaum sem foi favorável à arquitetura de microkernel, uma característica diferente do Minix até hoje (veja o texto "Por que os computadores não conseguem funcionar o tempo todo?"). Linus, por outro lado, fez o Linux com um kernel monolítico, com sistemas de arquivos, drivers e outros componentes incorporados dentro do kernel. Numa famosa postagem ao grupo Minix, o criador do Minix se referiu ao Linux como "... um gigante retrocesso ao anos 70", e uma confiante resposta do jovem Torvalds para esse experiente líder no campo dos sistemas operacionais é a primeira evidência da sua hoje legendária integridade. Apesar de tudo, Linus reconheceu a importância do trabalho de Tanenbaum para a formação de suas próprias idéias. Em sua autobiografia "Just for Fun", Linus se refere ao livro de Tanenbaum "Operating Systems: Design and Implementation" como um livro que mudou sua vida.

O debate entre microkerneis e kerneis monolíticos continua hoje em dia, e assim como o Linux não desapareceu, o Minix muito menos. A versão 3 do sistema operacional Minix foi projetado com o objetivo de criar um sistema que seja mais seguro e confiável do que os sistemas POSIX semelhantes, e uma licença livre estilo BSD faz do último Minix um forte candidato não só para o uso de produção, como também para o uso educacional. O Minix está atraindo até mesmo a atenção de alguns grandes patrocinadores. A União Européia está patrocinando o projeto com vários milhões de euros, e o Google tem uma quantidade de projetos relacionados ao Minix em seu programa "Summer of Code".

O Minix 3 roda tanto em processadores x86 32-bits quanto em várias máquinas virtuais, incluindo Qemu, Xen e VMWare. O sistema operacional inclui um sistema gráfico de janelas (X11), vários editores (Emacs e Vi), shells (incluindo o bash e o Zsh), GCC, linguagens de script, como Python e Perl, e ferramentas de rede - como o SSH. Com um design diminuto e resistente a erros, o Minix é um bom candidato para sistemas embarcados e a sua estabilidade superior tem conduzido a um novo e promissor papel como um sistema de firewall.

Inseguro pelo Design

Os problemas de segurança à frente da atual safra de sistemas operacionais, incluindo o Windows, mas também incluindo o Linux, são resultado de erros de design. Os erros foram herdados, em sua maior parte, de seus predecessores dos anos 60. A maioria desses problemas podem ser atribuídos ao fato de que os desenvolvedores não são perfeitos. Os humanos cometem erros. Claro, seria bom reduzir os números e mitigar os efeitos; entretanto, os programadores frequentemente estão dispostos a comprometer a segurança e um design limpo pela velocidade. Tanenbaum se refere a isso como um "pacto faustiano".
Além dessas questões relacionadas à dimensão, designs monolíticos também estão propensos a problemas estruturais inerentes: qualquer erro é capaz de comprometer o sistema como um todo. Um erro de design fundamental é que os sistemas operacionais atuais não seguem o Princípio da Menor Autoridade (POLA em inglês). Para esclarece isso, o POLA afirma que os desenvolvedores devem distribuir os sistemas sobre uma quantidade de módulos a fim de que um erro num módulo não comprometa a segurança e estabilidade dos outros módulos. Eles também devem garantir que cada módulo tenha apenas os direitos que ele realmente necessite para finalizar as funções designadas.
 
O contínuo crescimento do sistema operacional vem com a integração de novos drivers. Sistemas monolíticos incorporam drivers de dispositivos dentro do kernel, o que significa que um erro de driver pode comprometer todo o sistema. Drivers de código fonte fechado em particular colocam em risco a segurança do sistema. De acordo com Tanenbaum, incorporar um driver fechado no kernel é como aceitar um pacote lacrado de um estranho e levá-lo à cabine do avião.

Figura 1: O microkernel do Minix encapsula vários subsitemas na Área do Ususário, incluindo drivers, o sistema de arquivos e a pilha de rede. O kernel roda apenas funções críticas como operações de I/O, agendadores e gerenciamento de memória.

Arquitetura Transparente

O Minix é, provavelmente, o sistema operacional existente mais bem documentado. O "The Minix Book" de Tanenbaum e Woodhull é a referência principal. Inúmeras publicações sobre novas funções e pesquisas em andamento são encontradas na página principal do Minix. O Minix obedece ao padrãoPSIX IEEE 1003.2-1996 e os desenvolvedores já portaram muitos programas Unix para o Minix.

A Diferença do Minix

O Minix 3 está nos currículos de muitas universidades e muitas gerações de estudante já examinaram os poucos milhares de linhas do código do Minix e consertaram muitos erros. A arquitetura em microkernel implementa os drivers como processos de modos de usuários separados que não permitem executar comandos privilegiados ou operações de I/O (Entrada e Saída) ou escrever diretamente na memória. Em vez disso, essas operações são feitas por chamadas fiscalizáveis do kernel (ver Figura 1).

O Minix 3 utiliza mensagens de largura definida para a comunicação de processos. Esse design simplifica a estrutura do código e ajuda a mitigar o perigo de transbordamento de dados. O sistema de arquivos do Minix é executado como um simples processo de usuário. Já que ocupa cerca de 8.200 linhas do código da área de usuário, mas sem código do kernel, odebug nele é feito facilmente.

Um componente inovador, o "servidor de reincarnação", aumenta a confiabilidade do sistema Minix de servir como responsável por todos os servidores e drivers. Ele detecta erros muito rapidamente e monitora continuamente a função de processo críticos, reiniciando processos inoperantes quando necessário para manter o sistema rodando.

O Projeto Minix Firewall

Filtros de pacotes são um componente do sistema em risco. Apesar da excelente qualidade do Linux em implementações Nelfilter, várias questões de segurança surgiram no passado. Se um subsistema desse tipo está rodando no kernel Linux, ele estará colocando em risco a segurança do sistema. Com base no trabalho do grupo de Tanenbaum, a Universidade Técnica em Ciência Aplicada de Berlim portou o famosoframework Netfilter para o Minix 3.

Novamente, a estabilidade da arquitetura em microkernel oferece benefícios adicionais. No Linux, um invasor que tenha sucesso em provocar um erro - por exemplo, explorando um transbordamento de dados na função do_replace () - pode deixar um firewall Linux de joelhos. No Minix 3, um único processo de usuário poderia colapsar sem comprometer a segurança do sistema. O servidor de reincarnação poderia simplesmente reiniciar o processo.

As diferenças se tornam ainda mais aparente se um invasor tem sucesso ao executar um código. No Minix, um processo de usuário seqüestrado ainda é um problema. mas o efeito é muito mais brando graças à isolação.

Até a Microsoft está explorando o próprio sistema em microkernel, chamado Singularity. Embora o Minix tenha jogado o jogo do microkernel por anos, o seu maior obstáculo para se tornar mais conhecido sempre foi as suas licenças não livres. Agora que o Minix 3 está sendo distribuído sob uma licença BSD e as extensões de firewall estão disponíveis sob GPL, os pesquisadores daTFH Berlin estão trabalhando na exploração do potencial do Minix como um firewall virtualizado. Estabilidade, um design diminuto e um novo modelo de licenciamento deram ao Minix 3 um grande potencial de crescimento, especialmente em sistemas embarcados.

Figura 2: O Minix é bastante espartano na inicialização. Dito isso, a versão 3.1.2a incluí uma interface X11 e ferramentas para desenvolvedores.

Por que os computadores não conseguem funcionar o tempo todo?
Por Andrew S. Tanenbaum

Os usuários de computador estão mudando. Dez anos atrás, a maioria dos usuários de computador eram pessoas jovens ou profissionais com muita experiência técnica. Quando as coisas davam errado - e frequentemente davam -, eles sabiam como consertar as coisas. Hoje em dia, o usuário comum é muito menos sofisticado, talvez um garotinha de 12 anos ou um vovô. A maioria deles sabe tanto sobre arrumar computadores quando umnerd de computadores sabe sobre consertar o próprio carro. O que eles querem mais do que qualquer outra coisa é um computador que funcione o tempo todo, sem falhas ou erros.

Muitos usuários comparam automaticamente seus computadores com seus aparelhos de televisão. Ambos estão repletos de eletrônicos mágicos e têm telas grandes. A maioria dos usuários tem um modelo implícito de um aparelho de televisão: 1) você compra o aparelho; 2) o conecta; 3) ele funciona perfeitamente sem qualquer falha pelos próximos 10 anos. Eles esperam isso de um computador e quando não conseguem isso, ficam frustrados. Quando pessoas com alguma experiência em computação diz a eles: "Se Deus quisesse que os computadores funcionassem todo o tempo, Ele não teria inventado o botão RESET". Eles não se impressionam.

Na falta de uma definição melhor de confiabilidade, vamos adotar a seguinte: Um dispositivo é dito ser confiável se 99% dos usuários nunca experimentar qualquer falha durante o período de vida do próprio dispositivo. Por essa definição, virtualmente, nenhum computador é confiável, enquanto a maioria dasTV's, iPods , câmeras digitais, câmeras de vídeo, etc são. Viciados em tecnologia estão dispostos a perdoar um computador que falhe uma ou duas vezes por ano; usuários comuns não.

Usuários domésticos não são os únicos incomodados pela pobre confiabilidade dos computadores. Até mesmo em configurações altamente técnicas, a baixa confiabilidade dos computadores é um problema. Empresas como Google eAmazon , com centenas de servidores, experimentam várias falhas todos os dias. Eles aprenderam a conviver com isso, mas certamente iriam preferir sistemas que simplesmente funcionassem o tempo todo. Infelizmente, os softwares atuais os deixam na mão.

O problema básico é que o software contém bugs, e quanto mais softwares existem, mais bugs irão existir. Vários estudos têm mostrado que o número de bugs por milhar de linhas de código (KLoC) variam de 1 a 10 em grandes sistemas de produção. Um pedaço de um software bem escrito pode ter 2 bugs por KLoC com o passar do tempo, mas não menos. Um sistema operacional com, digamos, 4 milhões de linhas de código é, portanto, suscetível a ter ao menos 8000 bugs. Nem todos são fatais, mas alguns serão. Um estudo da Universidade de Stanford mostrou que drivers de dispositivos - que compõem 70% da base de códigos de um típico sistema operacional - têm taxas de bugs de 3 a 7 vezes maiores do que o resto do sistema. Drivers de dispositivos tem uma alta taxa de bugs porque (1) são mais complexos e (2) são menos examinados. Enquanto muitas pessoas estudam o agendador, poucas observam o driver da impressora.

A Solução: Kerneis Menores

A solução para esse problema é tirar o código do kernel, onde ele pode causar o máximo de estrago, e colocá-lo nos processos da área de usuário, onde bugs não conseguem causar falhas no sistema. É assim que o Minix foi projetado. O atual sistema Minix é o [segundo] sucessor do Minix original, que foi lançado originalmente em 1987 como um sistema operacional educacional mas tem sido corrigido desde então a fim de se tornar um sistema altamente confiável e auto-imune. O que segue é um breve descrição da arquitetura do Minix; você pode encontrar mais detalhes em http://www.minix3.org.

O Minix 3 foi projetado para rodar com o menor código possível no modo kernel, onde os bugs podem ser facilmente fatais. Em vez de 3 ou 4 milhões de linhas de código no kernel, o Minix 3 tem cerca de 5000 linhas de código no kernel. Às vezes kerneis tão pequenos são chamados de microkerneis. Eles lidam com o gerenciamento de processo de baixo nível - agendamento, interrupções e o relógio - e fornecem alguns serviços de baixo nível para componente da área de usuário.

O volume do sistema operacional roda como uma coleção de drivers e servidores de dispositivo, cada um rodando como um processo comum na área de usuário com privilégios restritos. Nenhum desses servidores e drivers rodam como super-usuário ou equivalente. Eles não podem nem mesmo acessar os dispositivos de entrada e saída ou a unidade de gerenciamento de memória diretamente (MMU).

Eles têm de usar os serviços do kernel para ler e escrever no hardware. A camada de processos rodando no modo de usuário acima do kernel consiste de drivers de dispositivos - com drivers de discos, drivers de rede e todos os outros drivers - rodando como processos separados protegidos pelaMMU do hardware a fim de que eles não possam executar quaisquer instruções privilegiadas e não possam escrever ou ler qualquer memória, exceto a própria.

Acima da camada de drivers vem a camada de servidores - com um servidor de arquivos, um servidor de processos e outros servidores. Os servidores fazem uso tanto dos drivers quanto dos serviços do kernel. Por exemplo, para ler de um arquivo, um processo de usuário manda uma mensagem para o servidor de arquivos, que então manda uma mensagem para o driver do disco buscar os blocos necessários. Quando o sistema de arquivos os tem no cache de dados, ele chama o kernel para movê-los para o espaço do endereço do usuário.

Além desses servidores, há um outro servidor chamado de servidor de reincarnação. O servidor de reincarnação é o responsável por todos processos de drivers e servidores e monitora o comportamento deles. Se ele descobre um processo que não está respondendo a seus pings, ele inicia uma nova copia pelo disco (exceto para o driver de disco, que é vigiado na RAM). O sistema foi projetado para que muitos (mas não todos) dos drivers e servidores críticos possam ser substituídos automaticamente enquanto o sistema está operante, sem perturbar os processos de usuário ou mesmo notificar o usuário. Dessa maneira, o sistema é auto-imune.

Para testar se essas idéias funcionam na prática, fizemos o seguinte experimento. Iniciamos um processo defeituoso por injection que sobrescreveu 100 instruções no binário do driver da rede para ver o que aconteceria se um deles fosse executado. Se nada acontecesse por alguns segundos, outras 100 instruções seriam introduzidas e assim por diante. Ao todo, injetamos 800.000 processos defeituosos em cada um dos três drivers de rede diferentes e causou 18.000 erros de driver. Em todos os casos, o driver foi substituído pelo servidor de reincarnação. Apesar de injetar 2.4 milhões de processos defeituosos no sistema, nenhuma vez sistema operacional falhou. Não precisa dizer que se um erro faltal ocorre num driver Linux ou Windows rodando no kernel, o sistema operacional por falharia completo instantaneamente.

Existe uma desvantagem nessa abordagem? Sim. Há uma meta de desempenho. Nós não medimos isso extensivamente, mas o grupo de pesquisa em Karlshure (Universidade de Karlshure, Alemanha), que desenvolveu o próprio microkernel, o L4, e depois rodou Linux sobre ele como um simples processo de usuário, foi capaz de atingir uma meta de desempenho de 5%. Acreditamos que, se colocarmos alguns esforços nele, poderemos alcançar a taxa entre 5% e 10% também. A performance não tem sido uma prioridade para nós, assim como a maioria dos usuários que lêem seus emails e entram no Facebook não estão limitados pela performance do CPU. O que eles querem, no entanto, é um sistema que funcione o tempo todo.

Se os microkerneis são tão confiáveis, por que todos não os usam?

Na verdade, todos usam. Provavelmente, você roda vários deles. O seu telefone celular, por exemplo, é um pequeno computador normal e há uma boa chance dele rodar o L4 ou o Symbian ou outro microkernel. Os roteadores de alta performance da Cisco usam. Nos mercados aeroespacial e militar, onde a confiabilidade é primordial, o Green Hills, outro microkernel, é amplamente usado. O PikeOS e o QNX também são microkerneis amplamente usados em sistemas embarcados e industriais. Em outras palavras, quando se trata de sistemas que "funcionem o tempo todo", as pessoas se voltam para os microkerneis. Para saber mais sobre esse assunto, acesse www.cs.vu.nl/~ast/reliable-os/.

Sendo assim, é o que acreditamos, baseado em várias conversas com usuário não técnicos, que o que eles querem acima de qualquer coisa é um sistema que funcione perfeitamente todo o tempo. Eles têm uma baixa tolerância para sistemas não confiáveis mas atualmente eles não têm escolhas. Acreditamos que sistemas baseados em microkerneis podem indicar o caminho para sistemas mais confiáveis.

Rüdiger Weis é professor de programação de sistemas na THF Berlin. Entre 2002 e 2005, ele esteve envolvido com uma pesquisa de pós-doutorado sistemas operacionais seguros sob a supervisão do Professor Andrew S. Tanenbaum na Vrije Universiteit, Amsterdã.

-*-*-*-*-*-*-*-*-*-*-*-*-

PDF (Inglês)
PDF (Português)

-*-*-*-*-*-*-*-*-*-*-*-*-

Pablo Hess, editor da Linux Magazine brasileira, me informou pelos comentário que o artigo do Tanenbaum já tinha sido traduzido pela revista. Não tinha conhecimento. Se você não entendeu alguma parte da minha tradução ou simplesmente não gostou, acesse AQUI a versão oficial do artigo publicado pela própria Linux Magazine Brasil.

Fotos direto do GIMP para o Flickr com o GimpPublishr

Se você usa o GIMP para retocar e melhorar as suas fotos antes de enviá-las para o Flickr, então, certamente, você gostará do plugin GimpPublishr. Ele permite que você envie a imagem do GIMP diretamente para a sua conta no Flickr ou Picasa. Para instalar o GimpPublishr, baixe a última versão do plugin no site do projeto, descompacte-o, e coloque a pasta libpub e o arquivo publishr.py na pasta ~/.gimp-x.x/plug-ins no seu diretório home (se a pasta plug-ins não existir, a crie).

Abra o GIMP, e você deverá ver a opção "Publish on Web" no menu Arquivo. Clique na opção e escolha o serviço que você deseja. Se você escolher o Flickr, você será perguntado para autorizar que o plugin acesse a sua conta no Flickr. Uma vez feito isso, dê um noma a sua foto, forneça uma descrição, especifique as tags, escolha a licença desejada e aperte no botão Upload. Simples assim.

Observação: Para autorizar no Flickr, copie a URL fornecida pelo plugin e abra no seu navegador. Já logado no Flickr, basta aceitar a permissão.

Fonte: Dmitri Popov@Linux Magazine

VNC no PCLinuxOS

Mais um tutorial "importado". Primeiramente, há duas formas de criar um servidor VNC: sem habilitar a parte gráfica e habilitando a parte gráfica. Sem a parte gráfica, você tem todos os comandos do servidor por um terminal no seu pc. Com o X habilitado, a navegação fica um pouco devagar - dependendo da conexão - mas é mais familiar. Vamos ao tutorial - mais uma vez feito pelo KDulcimer:

Por favor, note que o VNC é um protocolo que roda abertamente, sem segurança. Não tem problemas para a sua rede doméstica e, provavelmente, para a rede do seu trabalho, mas se você precisa de uma conxão VNC segura, você terá que pesquisar sobre tunelamento via SSH.

Você sabia que você pode acessar o desktop de um computador de outro máquina facilmente via VNC? O VNC é um pequeno protocolo que lhe permite ver o desktop de outro computador sobre uma rede.

Para usar o VNC, instale o tightvnc-server e um cliente VNC com o tightvnc. Abra um terminal no "servidor" e rode o comando "vncserver". Configure uma senha.

Ache o endereço IP do seu servidor. No terminal, faça o comando ifconfig. A segunda linha deve começar com "inet addr:". O que segue é o seu endereço IP.

Agora vá até a outra máquina na rede e inicie o tightvnc. Digite o endereço IP do servidor e adicione um ":1", ficará parecido com isto:

192.168.0.100:1

Não é muito se parece muito com um desktop, parece? Você tem apenas um terminal ou talvez nem isso. Volte ao o servidor e rode killall Xvnc para parar o servidor VNC.

Abra o arquivo ~/.vnc/xstartup num editor de texto e modifique-o com o que segue:

#!/bin/bash
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
startkde &

Observe que se você quer rodar algo além do KDE dentro da sessão VNC, você fazer isso mudando a linha "startkde &" para qualquer outro ambiente desktop que você deseja iniciar. Por exemplo, no meu sistema eu estou rodando o OpenBox, então eu coloquei:

#!/bin/sh
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
openbox-session &

Se você usa o GNOME use o código abaixo:

#!/bin/sh
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
unset SESSION_MANAGER
gnome-session &

Crie um arquivo chamado ~/.kde/Autostart/vncserver e coloque este código nele:

#!/bin/bash
if [ ! "$(pidof Xvnc)" ];
then vncserver;
else echo "vncserver is already running";
fi &

Observe que com esse código, se tiver mais de um usuário logado, somente o primeiro usuário terá uma sessão com o servidor VNC rodando.

Agora abra um terminal e rode este comando:

chmod 755 ~/.kde/Autostart/vncserver

Fiz um vídeo com a demonstração de como fica o uso do VNC por esse tutorial com o servidor em diferentes distribuições.

Como atualizar o PCLinuxOS sem internet

No fórum oficial do PCLinuxOS, o usuário KDulcimer postou um tutorial muito interessante que vale à pena ser reproduzido. Nesse tutorial, ele ensina como atualizar ou instalar novos programas noPCLinuxOS via Synaptic com o auxílio de uma máquina externa e um drive USB . Para quem tem internet discada, só tem acesso à internet no trabalho ou está impossibilitado de acessar a internet em casa esse tutorial é bem útil.

1. Primeiramente, abra o seu dispositivo USB e crie uma pasta chamada rpms na raiz do dispositivo. Dentro da pasta rpms, crie uma pasta chama base;

2. No local onde você tem acesso à internet, acesse um dos repositório do PCLinuxOS:
http://spout.ussg.indiana.edu/linux/pclinuxos/pclinuxos/apt/pclinuxos/2007/

3. Baixe todos os arquivos da pasta base e coloque-os no seu dispositivo USB dentro da pasta base.

4. Plugue o drive USB no computador que você quer atualizar e abra o dispositivo (tenha certeza que ele está montado). Agora, no seu gerenciador de arquivo, vá até /media e abra o drive. Copie o endereço que está na barra de endereço.

5. Abra o Synaptic. Vá até Settings -> Repositories -> New. Na seção URI, insira o seguinte:

file://

Então cole o endereço para o seu drive, ficará parecido com o seguinte:

file:///media/disk/

Na linha Distribution, coloque rpms. Na linha Section(s), deixe main extra nonfree kde.

6. Clique em OK e clique en Reload -> Mark All Upgrades. Agora vá até File -> Save Markings As..., dê um nome apropriado e salve esse arquivo no drive USB. Saia do Synaptic e escolha descartar as mudanças selecionadas;

7. Volte até o local que você tem acesso à internet, abra o arquivo num editor de texto, abra o repositório do PCLinuxOS no navegador e baixe os pacote que você precisa. Salve-os na pasta rpms;

8. Volte ao sistema que você quer atualizar, copie todos os RPMs (como root) da pasta rpms para a pasta /var/cache/apt/archives/;

9. Abra o Synaptic e clique em Mark All Upgrades -> Apply -> Apply.

Para instalar pacotes, o procedimento é muito parecido:

1. Deixe o seu sistema completamente atualizado seguindo os passo acima. Não pule essa etapa!;

2. Abra o Synaptic e marque as aplicações que você quer instalar. Agora vá até File -> Save Markings As..., dê um nome apropriado ao arquivo e salve-o no seu dispositivo USB. Saia do Synaptic e escolha descartar todas as mudanças selecionadas;

3. Vá até o local que você tem acesso à internet, abra o arquivo num editor de texto, abra o repositório do PCLinuxOS no navegador e baixe os pacote que você necessita. Salve-os na pasta rpms;

4. Volte ao sistema que você quer atualizar, copie todos os RPMs (como root) da pasta rpms para a pasta /var/cache/apt/archives/;

5. Abra o Synaptic vá até File -> Read Markings -> Selecione o arquivo que você criou na etapa 2 -> Apply -> Apply.

Reforma ortográfica

2009 começa com a essa maldita reforma ortográfica. Protesto!! Quero o meu acento nas paroxítonas terminadas em ditongo aberto!! Quero o trema - ninguém usa ele, mas se inventaram é porque tem algum uso!! Quero o acento diferencial - não viverei sem o pára/para!! Nesse blog essa reforma não entra!! Serei o Policarpo Quaresma da paroxítona com ditongo aberto acentuada.

Entrevista com Martin Nordholts, desenvolvedor do GIMP

O site Linux Photography fez uma entrevista com Martin Nordholts, desenvolvedor do GIMP, tratando de vários assuntos - previsões de novas funções, integração com o GEGL, novas funcionalidade que serão acrescentadas na versão 2.8 e muito mais.

Linux Photography: Martin, obrigado por dispor um tempo para essa entrevista. Para começar, você pode nos dizer algumas palavras sobre você e sobre o seu envolvimento com o GIMP?

Martin Nordholts: Depois da minha primeira contribuição, em outubro de 2006, gradualmente me envolvi cada vez mais e hoje estou dando contribuições mais ou menos diárias, incluindo conserto de bugs, mantendo relatórios de erros, revisando e unindo códigos e trabalhando em novas funcionalidades. Ocasionalmente, eu também contribuo com o framework GEGL, mas o GIMP ocupa a maior parte do meu tempo. Em meu trabalho cotidiano, eu trabalho como desenvolvedor de software para uma famosa fabricante de telefones móveis.

LP: Falando do ponto de vista de um fotógrafo, há uma longa espera por funcionalidades como gerenciamento de cores, edição de cores em maior profundidade ou "efeito em camadas" a serem incluídas no GIMP. Agora que o GEGL está pronto para o prime time, como que o uso do GEGL no GIMP permitirá essas funcionalidades?

MN: Quando o GEGL estiver completamente integrado, o GIMP oferecerá edição de cores em alta profundidade e não destrutiva incluindo o tão falado efeito em camadas. O gerenciamento de cores é uma questão separada e um gerenciamento de cores de alta qualidade irá requerer trabalho no framework GEGL e no núcleo do GIMP.

LP: Com a versão 2.6 do GIMP recém lançada, o GEGL é usado no GIMP para muitas operações. Qual é a quantidade de trabalho ainda necessária para que o GEGL esteja pronto para ser usado plenamente no GIMP?

MN: Para o GIMP 2.6, muitas operações de cores foram portadas para o GEGL. Para o GIMP 2.8, já acabamos a projeção de código para o GEGL também. A projeção de código é o que combina as camadas em um único objeto - por exemplo uma imagem. Com a estrutura da imagem representada como um gráfico GEGL, é fácil inserir nodes não destrutivos e sei que o Øyvind - desenvolvedor do GIMP - está fazendo alguns protótipos que, até onde sei, são quase indolores.

Poderíamos dizer que o GIMP tem um núcleo isolado capaz de fazer edição de cores em grande profundidade e não destrutiva. O que precisa ser feito é adaptar o código para que os usuários possam usar plenamente esse núcleo atualmente isolado. É impossível e inútil especular sobre uma data específica em que isso estará finalizado. Apenas podemos afirmar que o trabalho está sendo feito e eventualmente estará acabado.

LP: Como foi a integração do GEGL no GIMP 2.6? Você sente que o trabalho de base feito nas versões anteriores do GIMP está dando bons frutos; e processo foi relativamente simples ou você o descreveria como "doloroso"?

MN: O trabalho que tem sido feito até agora (incluindo no 2.8) tem sido bastante simples. Como muitas vezes é o caso, só é necessário algum tempo dedicado para pensar e programar.

LP: Agora as perguntas queria perguntar há muito tempo (e provavelmente não sou o único...). Em quanto tempo veremos as diferentes funções mencionadas anteriormente serem incluídas no GIMP? Talvez possamos falar sobre o gerenciamento de cores primeiro: ele está lá agora nas preferências do GIMP e no menu "Imagem". Sinto que tenho tudo que necessito para um avanço em cores gerenciadas, mas você planeja adicionar mais algumas funções? O código atual precisa de mudanças drásticas para ser compatível com o GEGL?

MN: Eu mesmo estou interessado em melhorar o gerenciamento de cores, mas não darei atenção especial a ele antes que o GEGL estiver quase completamente integrado. Especular sobre datas específicas é, repito, impossível e inútil. Algum programador pode se interessar e começar a trabalhar nesse exato momento, ou pode levar muitos anos até que alguém ache tempo e motivação suficientes para melhorar a situação.

LP: A próxima questão é sobre uma maior profundidade de cores - um assunto querido por um coração de fotógrafo. Se 8bits por canal presume ser o código inteiro, posso imaginar que mudar essa suposição significa refazer tudo. Está correto? Quais são os principais desafios para se ter uma versão do GIMP com mais bits por canal?

MN: Já que o GEGL é um framework novo, realmente não há por que reescrever o código herdado de 8bits por canal, mas sim substituir esse código inteiramente. Fará sentido escrever wrappers* para os componentes herdados para também serem usados com o novo framework , mas isso não é exatamente reescrever o código. Na verdade, não vejo grandes desafios a não ser a maior profundidade de cores, o código simplesmente precisa se escrito.

Planos a longo prazo não funcionam bem num projeto dirigido por voluntários, mas existem alguns planos soltos. Se nada der errado, o GIMP 2.8 terá a projeção de código portada para o GEGL. Quando isso estiver terminado, o passo natural é começar a realmente usar o novo framework e suas novas funções. Talvez o GIMP 2.10 fará uso disso de alguma maneira.

LP: E agora sobre o "efeito em camadas" ou ainda melhor: edição não destrutiva (uma função doida e legal, se me perguntar)?

MN: A não destrutividade será fácil porque os paths do código herdado de 8 bits por canal ainda podem ser usados para transferir informações. A maior profundidade de cores será difícil devido à necessidade de novos/mais paths. O gerenciamento de cores é a parte mais difícil porque isso afeta toda a estrutura da edição de imagem.

LP: Isso também clama por uma pergunta sobre o design da interface de usuário - editar imagem é uma tarefa complexa e uma interface de usuário simples para uma tarefa complexa não é fácil?

MN: O time responsável pela interface de usuário (principalmente Peter Sikking) está dando uma contribuição valiosa. Sei que existem planos para uma interface de usuário para as função não destrutivas mas não me lembro de nenhum detalhe no momento.

LP: Existe mais algumas funções que você gostaria de mencionar?

MN: Existem discussões sobre uma interface baseada numa janela única por aba que pode, provavelmente, interessar algumas pessoas. As recentes mudanças também fizeram progresso em direção a uma melhor manipulação de seleções flutuantes e suporte para grupo de camadas que até podem estar no GIMP 2.8. O GIMP 2.8 também contará com três projetos do Google Summer of Code que estão em processo de fusão, chamados simple vector layer support, on-canvas text editing e tagging of GIMP resources.

LP: Quais são as áreas em que o GIMP se beneficia de ajuda?

MN: Na verdade, não acredito em chamar por ajuda. Se as pessoas estão interessadas em ajudar, elas ajudarão. Caso contrário, não irão. Pessoas em todas as áreas são bem-vindas. Desenvolvedores, mantenedores de relatórios de erros, mantenedores do website, autores de documentação, etc, etc.

LP: Sei que você pode ou não estar interessado em fotografia, mas qual é a sua opinião sobre o nível dos programas open source para fotografia em geral?

MN: Devo admitir que não sou muito interessado em ser fotógrafo. A fotografia me interessa mas nunca tive tempo para realmente fazer algo sério. Eu não sou, em outras palavras, a pessoa certa para julgar a qualidade dos programas open source para fotografia do ponto de vista de um profissional. Mas todos nós podemos ver que os programas estão em constante evolução e novos programas estão surgindo, a situação está melhorando continuamente.

LP: Fazendo o papel de advogado do diabo: com grandes desenvolvedoras se tornando cada vez mais poderosas e capazes de lidar com diferentes tipos de arquivos de imagem, ainda há espaço para um "bom e velho editor" como o GIMP?

MN: O que posso dizer? Se algum outro editor superar o GIMP em termos de ferramentas, que assim seja. Entretanto, suspeito que, uma vez que nós tenhamos acabado o trabalho que atualmente estamos fazendo, o GIMP será muito atrativo para as pessoas que atualmente se dedicam a processamento de profundidade com grande quantidade de bits por exemplo. Acho a competição (se alguém quiser usar esse termo) nada além de interessante.

----------------------

Correções?? Manda nos comentários!!!!