Como o próprio título diz, após mais de dois anos sem encostar no meu Arch, resolvi reinstalar pra ver como andava o estado da ferrugem. Não é uma volta ao blog, mas uma volta ao sistema e depois de um tempo afastado foi bom pra ver a evolução dos aplicativos e do suporte. Uma coisa que fez muita diferença foi essa externalização dos serviços - chat do facebook, música com o grooveshark, etc - tornando desnecessária a instalação de muitos softwares. Ponto pra nós. Muita coisa evoluiu - algumas muito outras muito pouco - e algumas coisas pararam no tempo. Nos vemos em breve..
Obs.: apesar de anos no Arch, nessa volta tomei um laço como de costume.
Kernel Linux em Poucas Palavras – Parte 3
Se tiver alguma dúvida, consulte os PDFs em inglês disponibilizados no fim do post.
Quando você está compilando o seu próprio kernel, você deseja ter a versão estável mais recente. Muitas distribuições fornecem seus próprios pacotes com os códigos-fonte, mas elas raramente são as versão mais recentes do kernel. Os pacotes de distribuições tem a vantagem de ter sido feito para ser compatível com o compilador e outras ferramentas fornecidas pela distribuição (o capítulo 2 explica a importância delas serem compatíveis) mas elas podem acabar não tendo a funcionabilidade e performance que você deseja. Se você quer criar o seu própro ambiente com a versão mais recente do kernel, compilador e outras ferramentas, você será capaz de criar exatamente o que você deseja. Essa capítulo se foca em determinar quais ódigos-fonte do kernel baixar e como obtê-las.
Qual Árvore Usar
No passado, o kernel Linux era separado em somente duas árvores, a versão "development" e a versão "stable". A versão development era indicada por um número ímpar no segundo número da versão, enquanto a versão stable usava números pares. Então, como exemplo, a versão 2.5.25 era um kernel em desenvolvimento, enquanto a versão 2.4.25 é uma versão estável.
Mas depois que a série 2.6 foi criada, os desenvolvedores do kernel decidiram abandonar esse método de ter duas árvores separadas e declararam que todas as versões do kernel 2.6 seriam consideradas "estáveis", não importando a velocidade do desenvolvimento. Os poucos meses entre os principais lançamentos da série 2.6 dariam aos desenvolvedores do kernel tempo para adicionar novas funcionalidades e então estabilizá-las a tempo do próximo lançamento. Além disso, uma ramificação "-stable" foi criada para arrumar bugs das versões e atualizações de segurança para versões passadas do kernel, antes que a próxima versão principal da série 2.6 seja lançada.
Tudo isso é melhor explicado com alguns exemplos, ilustrados na Figura 3.1. A equipe do kernel lançou o kernel 2.6.17 como uma versão estável. Então os desenvolvedores iniciaram o trabalho em novas funcionalidades e iniciaram lançando versões -rc como kernels em desenvolvimento para que as pessoas pudessem ajudar a testar e debugar as mudanças. Após que todos concordaram que a versão em desenvolvimento estava estável o suficiente, ela foi lançada como o kernel 2.6.18. Todo esse ciclo normalmente leva cerca de 2 ou três meses, dependendo de uma variedade de fatores.
Figura 3-1. Ciclo de lançamento do desenvolvimento do kernel.
Enquanto o desenvolvimento de novas funcionalidades estava ocorrendo, a versões estáveis 2.6.17.1, 2.6.17.2 e outras foram lançadas, contendo conserto de bugs e atualizações de segurança.
Se você deseja usar a versão mais recente no seu trabalho, é recomendado que você utilize as versões estáveis do kernel. Se você deseja ajudar os desenvolvedores do kernel a testar as funcionalidades da próxima versão do kernel e fazer um feedback, utilize a versão do kernel em desenvolvimento. Para efeito desse capítulo, assumiremos que você está usando uma versão estável do kernel.
Onde Achar o Código-Fonte do Kernel
Todos os códigos-fonte do kernel Linux podem serem encontrados em um do sites do kernel.org, uma rede mundial de servidores que hospedam o código-fonte do Linux, habilitando qualquer um encontrar um servidor local perto de si. Isso permite que os principais servidores do kernel sejam suscetíveis aos sites que hospedam os códigos-fonte e permite que os usuários baixem os arquivos necessários o mais rápido possível.
O site principal - http://www.kernel.org - mostra todas as versões atuais do kernel de várias árvores diferentes do kernel, como mostrado na Figura 3.2.
Figura 3-2. O site principal do projeto kernel.org
Para baixar a versão estável mais recente do kernel, clique no caracter F na linha da versão do kernel. Isso baixará o código-fonte inteiro da árvore. Ou você pode navegar até a sub-pasta apropriada para ver todas as versões do kernel da série 2.6, http://www.us.kernel.org/pub/linux/kernel/v2.6, como é mostrado na Figura 3-3.
Também é possível baixar o código-fonte do kernel pela linha de comando, utilizando as ferramentas wget e curl, ambas devem vir na sua distribuição Linux.
Para baixar a versão 2.6.17.8 do kernel usando o wget, insira o comando:
$ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.8.tar.gz
--17:44:55-- http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.8.
tar.gz
=> `linux-2.6.17.8.tar.gz'
Resolving www.kernel.org... 204.152.191.5, 204.152.191.37
Connecting to www.kernel.org|204.152.191.5|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 51,707,742 (49M) [application/x-gzip]
100%[=============================================>] 51,707,742 35.25K/s
ETA 00:00
18:02:48 (47.12 KB/s) - `linux-2.6.17.8.tar.gz' saved [51707742/51707742]
Figura 3-3. A pasta do código-fonte do kernel 2.6
Para baixar usando curl:
$ curl http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.8.tar.gz \
-o linux-2.6.17.8.tar.gz
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 49.3M 100 49.3M 0 0 50298 0 0:17:08 0:17:08 --:--:--
100k
Uma maneira rápida e fácil para ver a versão do kernel mais recente, use a informação disponível em http://www.kernel.org/kdist/finger_banner, ilustrado pela Figura 3-4.
O Que Fazer Com O Código-Fonte
Agora que você baixou o código-fonte do kernel apropriado, onde ele deve ficar? Aconselhamos criar um diretório local na sua pasta home chamada linux para guardar dos os arquivos de códigos-fonte de diferentes versões do kernel:
$ mkdir ~/linux
Figura 3-4. Versão do kernel mais recente
Agora mova o código-fonte para esse diretório:
$ mv ~/linux-2.6.17.8.tar.gz ~/linux
E entre no diretório:
$ cd ~/linux
$ ls
linux-2.6.17.8.tar.gz
Agora que o código-fonte está na pasta correta, descompacte o arquivo:
$ tar -xzvf linux-2.6.17.8.tar.gz
A tela será preenchida com os arquivos que são descompactados e aparecerá seguinte no diretório linux/:
$ ls
linux-2.6.17.8.tar.gz
linux-2;6;17.8/
PDF em inglês - Chapter 3: Retrieving the Kernel Source
Qualquer correção, crítica & derivados, nos comentários por favor. Agradecido.
*---*---*---*---*---*---*---*---*---*---*
Obtendo o Kernel LinuxQuando você está compilando o seu próprio kernel, você deseja ter a versão estável mais recente. Muitas distribuições fornecem seus próprios pacotes com os códigos-fonte, mas elas raramente são as versão mais recentes do kernel. Os pacotes de distribuições tem a vantagem de ter sido feito para ser compatível com o compilador e outras ferramentas fornecidas pela distribuição (o capítulo 2 explica a importância delas serem compatíveis) mas elas podem acabar não tendo a funcionabilidade e performance que você deseja. Se você quer criar o seu própro ambiente com a versão mais recente do kernel, compilador e outras ferramentas, você será capaz de criar exatamente o que você deseja. Essa capítulo se foca em determinar quais ódigos-fonte do kernel baixar e como obtê-las.
Qual Árvore Usar
No passado, o kernel Linux era separado em somente duas árvores, a versão "development" e a versão "stable". A versão development era indicada por um número ímpar no segundo número da versão, enquanto a versão stable usava números pares. Então, como exemplo, a versão 2.5.25 era um kernel em desenvolvimento, enquanto a versão 2.4.25 é uma versão estável.
Mas depois que a série 2.6 foi criada, os desenvolvedores do kernel decidiram abandonar esse método de ter duas árvores separadas e declararam que todas as versões do kernel 2.6 seriam consideradas "estáveis", não importando a velocidade do desenvolvimento. Os poucos meses entre os principais lançamentos da série 2.6 dariam aos desenvolvedores do kernel tempo para adicionar novas funcionalidades e então estabilizá-las a tempo do próximo lançamento. Além disso, uma ramificação "-stable" foi criada para arrumar bugs das versões e atualizações de segurança para versões passadas do kernel, antes que a próxima versão principal da série 2.6 seja lançada.
Tudo isso é melhor explicado com alguns exemplos, ilustrados na Figura 3.1. A equipe do kernel lançou o kernel 2.6.17 como uma versão estável. Então os desenvolvedores iniciaram o trabalho em novas funcionalidades e iniciaram lançando versões -rc como kernels em desenvolvimento para que as pessoas pudessem ajudar a testar e debugar as mudanças. Após que todos concordaram que a versão em desenvolvimento estava estável o suficiente, ela foi lançada como o kernel 2.6.18. Todo esse ciclo normalmente leva cerca de 2 ou três meses, dependendo de uma variedade de fatores.
Figura 3-1. Ciclo de lançamento do desenvolvimento do kernel.
Enquanto o desenvolvimento de novas funcionalidades estava ocorrendo, a versões estáveis 2.6.17.1, 2.6.17.2 e outras foram lançadas, contendo conserto de bugs e atualizações de segurança.
Se você deseja usar a versão mais recente no seu trabalho, é recomendado que você utilize as versões estáveis do kernel. Se você deseja ajudar os desenvolvedores do kernel a testar as funcionalidades da próxima versão do kernel e fazer um feedback, utilize a versão do kernel em desenvolvimento. Para efeito desse capítulo, assumiremos que você está usando uma versão estável do kernel.
Onde Achar o Código-Fonte do Kernel
Todos os códigos-fonte do kernel Linux podem serem encontrados em um do sites do kernel.org, uma rede mundial de servidores que hospedam o código-fonte do Linux, habilitando qualquer um encontrar um servidor local perto de si. Isso permite que os principais servidores do kernel sejam suscetíveis aos sites que hospedam os códigos-fonte e permite que os usuários baixem os arquivos necessários o mais rápido possível.
O site principal - http://www.kernel.org - mostra todas as versões atuais do kernel de várias árvores diferentes do kernel, como mostrado na Figura 3.2.
Figura 3-2. O site principal do projeto kernel.org
Para baixar a versão estável mais recente do kernel, clique no caracter F na linha da versão do kernel. Isso baixará o código-fonte inteiro da árvore. Ou você pode navegar até a sub-pasta apropriada para ver todas as versões do kernel da série 2.6, http://www.us.kernel.org/pub/linux/kernel/v2.6, como é mostrado na Figura 3-3.
Também é possível baixar o código-fonte do kernel pela linha de comando, utilizando as ferramentas wget e curl, ambas devem vir na sua distribuição Linux.
Para baixar a versão 2.6.17.8 do kernel usando o wget, insira o comando:
$ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.8.tar.gz
--17:44:55-- http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.8.
tar.gz
=> `linux-2.6.17.8.tar.gz'
Resolving www.kernel.org... 204.152.191.5, 204.152.191.37
Connecting to www.kernel.org|204.152.191.5|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 51,707,742 (49M) [application/x-gzip]
100%[=============================================>] 51,707,742 35.25K/s
ETA 00:00
18:02:48 (47.12 KB/s) - `linux-2.6.17.8.tar.gz' saved [51707742/51707742]
Figura 3-3. A pasta do código-fonte do kernel 2.6
Para baixar usando curl:
$ curl http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.8.tar.gz \
-o linux-2.6.17.8.tar.gz
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 49.3M 100 49.3M 0 0 50298 0 0:17:08 0:17:08 --:--:--
100k
Uma maneira rápida e fácil para ver a versão do kernel mais recente, use a informação disponível em http://www.kernel.org/kdist/finger_banner, ilustrado pela Figura 3-4.
O Que Fazer Com O Código-Fonte
Agora que você baixou o código-fonte do kernel apropriado, onde ele deve ficar? Aconselhamos criar um diretório local na sua pasta home chamada linux para guardar dos os arquivos de códigos-fonte de diferentes versões do kernel:
$ mkdir ~/linux
Figura 3-4. Versão do kernel mais recente
Agora mova o código-fonte para esse diretório:
$ mv ~/linux-2.6.17.8.tar.gz ~/linux
E entre no diretório:
$ cd ~/linux
$ ls
linux-2.6.17.8.tar.gz
Agora que o código-fonte está na pasta correta, descompacte o arquivo:
$ tar -xzvf linux-2.6.17.8.tar.gz
A tela será preenchida com os arquivos que são descompactados e aparecerá seguinte no diretório linux/:
$ ls
linux-2.6.17.8.tar.gz
linux-2;6;17.8/
*---*---*---*---*---*---*---*---*---*---*
PDF em inglês - Chapter 3: Retrieving the Kernel Source
*---*---*---*---*---*---*---*---*---*---*
Qualquer correção, crítica & derivados, nos comentários por favor. Agradecido.
Uma notícia, uma frase
Notícia:
"PSL Brasil: ASL.org critica acordo gaúcho com Microsoft"
Frase:
"Não queiram ser como aqueles que passam metade da vida a dizer o que vão realizar e a outra metade a explicar porque não o realizaram." ~ Benjamin Franklin
"PSL Brasil: ASL.org critica acordo gaúcho com Microsoft"
Frase:
"Não queiram ser como aqueles que passam metade da vida a dizer o que vão realizar e a outra metade a explicar porque não o realizaram." ~ Benjamin Franklin
Um benchmak multiplataforma do OpenOffice
O resultado?? Qual a diferença entre uma Ferrari a 300 Km/h e uma Lamborghini a 305 Km/h?? É mais ou menos essa a diferença.
Detectando o Conficker no Linux
1. O "The Honeynet Project" fez um script em python (que requer a biblioteca Impact - para instalar basta o comando "python setup.py install") tanto para Linux quanto para Windows. O scanner é rápido e prático. Basta instalar a biblioteca e rodar o comando "./scs.py [primeiro_IP] [ultimo_IP]". Se você só tem uma máquina para escanear, basta colocar o IP da máquina nos dois parâmetros e pronto. Algo parecido com isso aparecerá:
192.168.0.151: No resp. (445/tcp)
192.168.0.145: Windows 5.1 [Windows 2000 LAN Manager]
.151 é a minha máquina Linux e .145 é o meu desktop Windows com o compartilhamento ativado.
Esse método analisa se o PC está infectado com as variações .A, .B e .C no Conficker. Porém, para ver se a sua máquina está com as variações .B e .C basta entrar nessa página hospedada pela Universidade de Bonn.
2. O outro método é instalar uma nova versão do famosíssimo NMAP feito justamente para isso. Instale a versão 4.85BETA6 e rode o seguinte comando:
nmap -PN -d -p445 --script=smb-check-vulns --script-args=safe=1 [faixa_de_IP]
Entenda-se por faixa de IP algo como 192.168.0.1-255.
That's all folks!!!
Ainda estou aqui
Um mês depois, descobri o valor do tempo. Achava que o ditado "tempo é dinheiro" não fosse tão importante na vida, mas talvez seja um dos principais até se descobrir que o que mais está em extinção não é nem os pandas gigantes da China, nem alguma das milhares de espécies de sapos em alguma floresta no mundo. É o nosso amigo tempo. E não há nenhuma ONG para protege-lo.
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.
*---*---*---*---*---*---*---*---*---*---*
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.
*---*---*---*---*---*---*---*---*---*---*
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.
*---*---*---*---*---*---*---*---*---*---*
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..
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:
Fonte: Ubuntu.com
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.
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ê.
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!!
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.
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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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:
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.
[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.
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"
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
