Tag Archive | Archlinux

Adeus chroot… seja bem vindo LXC…

Eu já escrevi sobre como instalar o Ubuntu em um ambiente chroot antes, mas recentemente descobri que o kernel fornece uma interface mais poderosa de isolar pedaços do sistema, com a qual novas ferramentas têm sido criadas. Uma dessas ferramentas é a ferramenta LXC.

Chroot

O chroot é uma chamada de sistema do sistema operacional que permite mudar o diretório raiz de processos-filhos. Usando esse recurso, você pode, por exemplo, manter uma distribuição Linux secundária instalada em uma pasta (no lugar de uma partição) e executar programas desse lugar sem uma perda de desempenho significativa que ocorre com máquinas virtuais, algumas vezes.

Uma das técnicas para criar um ambiente seguro é isolar o acesso de componentes que não confiem (ou não o precisem) uns nos outros. Em sistemas baseados em Unix, incluindo o GNU/Linux, temos usuários, grupos e o avançado sistema de permissões para “cumprir” essa condição.

Dessa forma, você só precisa ter “paranoia” em evitar que processos consigam acesso ao usuário root. Alguns leitores podem pensar que chroot seria a solução do problema, já que processos rodando dentro da jaula chroot ficariam incapacitados de ler arquivos de fora da jaula. Entretanto, mesmo dentro da jaula, um usuário root ainda é muito poderoso. Um primeiro exemplo:

shot-2013-02-23_14-49-44

shot-2013-02-23_14-57-09

shot-2013-02-23_14-57-32

O exemplo anterior pode ter parecido um pouco inútil, mas seu objetivo foi apenas mostrar que isolar arquivos não é suficiente caso o ambiente dentro da jaula de chroot consiga acesso ao usuário root. Na verdade, como mostra o exemplo seguinte (consulte o asciinema para versão animada), caso o ambiente dentro da jaula de chroot consiga acesso ao usuário root e chroot seja a única técnica de segurança, nem mesmo isolamento de arquivos é alcançado.

shot-2013-02-23_14-48-56

Citando a manpage sobre a chamada chroot:

This call changes an ingredient in the pathname resolution process and does nothing else.

[…]

This call does not close open file descriptors, and such file descriptors may allow access to files outside the chroot tree.

Concluindo, o chroot não livra você da responsabilidade de cuidar da segurança do sistema ou cria um ambiente que pode ser usado para testar software não confiável. O que o chroot fornece é um modo flexível de isolar a hierarquia de arquivos, permitindo, por exemplo, que você execute executáveis (até um determinado ponto) conflitantes no mesmo sistema.

Linux containers, namespaces s LXC

LXC é o nome da ferramenta responsável por gerenciar containers e namespaces. É um projeto legal que fornece uma biblioteca, vários bindings e ferramentas.

https://asciinema.org/a/7831

Um container seria algo parecido com uma jaula chroot, uma forma de isolar componentes do sistema. Do ponto de vista do LXC, a diferença é o nível de segurança que o container fornece, pois o objetivo do container é fornecer acesso isolado a qualquer recurso que possa ser utilizado para controlar ou acessar o sistema fora do container. Uma vantagem-bônus é que o container possui sua própria visão dos processos (o PID) e, assim, é possível usar um init no mesmo.

https://asciinema.org/a/7832

É possível conseguir essa segurança com máquinas virtuais, mas você perde algum desempenho optando por essa solução. Há bastante recursos que vêm sendo investidos para tornar o desempenho de máquinas virtuais mais rápidas, incluindo instruções de virtualização embutidas na CPU, especificação de hardware inexistente, mas que pode ser emulada com um desempenho melhor e mais fácil, drivers implementando a interface de hardware inexistente para sistemas operacionais que irão ser executados em máquinas virtuais, gerenciadores de máquinas virtuais embutidos no kernel com acesso direto ao hardware, …

https://asciinema.org/a/7833

Você tem, de um lado, uma solução com segurança e menos desempenho e, do outro, uma solução com desempenho e menos segurança. Ambos são peças de software complexas e difíceis de desenvolver (e desenvolver da forma certa, sem abrir um novo buraco de segurança).

Uma das propostas para melhorar a segurança sem recorrer a virtualização é construir (e usar) uma interface de userspace mais poderosa capaz de criar ambientes isolados, que seriam gerenciados pelo próprio kernel, e, além disso, teriam um gargalo bem menor de desempenho. Essa interface já existe no Linux e pode ser utilizada por ferramentas como o systemd-nspawn e lxc. O systemd-nspawn não tem foco na segurança, mas sim em capacidades de debug, então não será mais citado nesse texto.

É chegado o momento

Para tornar o texto mais claro, irei usar os termos hospedeiro e convidado para me referenciar, respectivamente, ao sistema inicial no qual você quer instalar o LXC e o novo ambiente, que irá ser executado dentro do container LXC.

Crie uma estrutura para um ambiente chroot seguindo as instruções na wiki do ArchLinux (ou esse segundo artigo, mais detalhado) e depois instale, adicionalmente, o pacote systemd-sysvcompat. Esse pacote não é listado como necessário em instruções de chroot, porque ele não é necessário para ambientes chroot, mas containers são ambientes mais isolados que ambientes chroot e ainda precisam de um init para funcionar (de forma mais fácil, ou mais completa, se preferir). Lembre de instalar outros programas que você queira acessar dentro do ambiente (como o firefox, por exemplo).

Com o seu rootfs pronto, é hora de configurar o container. Para gerar a configuração inicial do container, use o seguinte comando, como root:

Agora mova o seu rootfs para a pasta /var/lib/lxc/nome_do_seu_container. O meu arquivo config foi baseado no template do ArchLinux e tem o seguinte conteúdo:

Meu arquivo /var/lib/lxc/nome_do_seu_container/fstab ficou com o seguinte conteúdo:

Agora você pode iniciar o seu container usando o seguinte comando (como root):

E pará-lo usando esse outro (como root):

Configuração de rede

Grande parte das instruções abaixo eu aprendi na wiki do Arch.

Instale o pacote netctl no ambiente hospedeiro e o pacote iproute2 no ambiente convidado. Então crie, no ambiente hospedeiro, o arquivo /etc/netctl/nat com o seguinte conteúdo:

Depois inicie e habilite o serviço netctl para o perfil criado (nat) com os comandos, no ambiente hospedeiro:

Últimas mudanças no ambiente hospedeiro para habilitar a rede:

Depois crie o arquivo (dentro do convidado) etc/systemd/system/multi-user.target.wants/routes.service, com o seguinte conteúdo:

Agora execute esse serviço no ambiente convidado:

Algo que não é necessário, mas é bastante útil, é editar o arquivo /etc/hosts de ambos ambientes (hospedeiro e convidado) e incluir alias para os ips que são chatos para memorizar:

  • 192.168.100.1: Hospedeiro
  • 192.168.100.2: Convidado

Rodando aplicações que usem o X

Para conseguir rodar aplicações que usem o X de forma fácil, vamos usar o X11Forward via ssh, que fornece um túnel seguro para o tráfego de dados. É claro que as aplicações estão rodando em rede, mas é uma rede virtual acessível somente do seu computador local, então a “segurança” extra fornecida pelo ssh é desnecessária e, à primeira vista, serve somente como um gargalo a mais de desempenho. O real motivo de eu optar pelo ssh foi a facilidade (configura o ambiente X e outras coisas para você), mas o ssh fornece sim algumas opções para melhorar a segurança.

Antes de entrar em mais detalhes sobre as consequências da escolha por ssh, a descrição do processo é mais útil. Para rodar aplicações dentro dessa configuração, instale os pacotes xorg-server, xorg-xauth e openssh no ambiente convidado. Então edite o arquivo /etc/ssh/sshd_config adicionando seguinte a linha:

Agora execute o comando abaixo para executar o serviço sshd e permitir que o mesmo seja iniciado junto com o sistema operacional (convidado):

Pronto! Agora você pode executar aplicação X dentro do ambiente convidado usando o servidor X do ambiente hospedeiro. Se quiser iniciar o chromium do ambiente convidado, por exemplo, execute o seguinte comando dentro do ambiente hospedeiro:

A opção -X habilita o encaminhamento de pacotes relacionados ao servidor X para o ambiente hospedeiro. A opção -X faz o encaminhamento funcionar sob certas restrições, desabilitando algumas extensões que os desenvolvedores do ssh não consideram completamente seguras. Assim sendo, talvez nem todas as aplicações funcionem dessa forma. Uma opção substituta para pessoas menos paranoicas é a opção -Y. Por exemplo, a seguinte saída no chromium só acontece quando eu o executo sob menos privilégios (opção -X):

Nesse momento você deve ter percebido que o ssh fornece sim alguma segurança adicional. O último passo para essa seção é configurar o ambiente convidado para que ele pare de perguntar a senha toda vez que você quer logar (isso é incômodo). Para tal, execute os seguintes comandos:

Para mais informações sobre execução remota de aplicações X, visite a wiki do ArchLinux.

Configuração de placa de vídeo

SIM, eu tive todo esse trabalho (o trabalho maior é a parte de pesquisa/encontrar-documentação, pois usar essas ferramentas é fácil) para usar o Steam e jogos closed-source sem ficar *muito* paranoico. É claro que não adiantaria utilizar todo esse esquema de “segurança” se você utilizasse um módulo do kernel fechado da NVidia, mas os drivers open source já são bons o suficiente para eu jogar alguns jogos 3D no meu bem modesto netbook.

Altere o arquivo de configuração do container LXC e adicione a seguinte linha:

Depois crie o arquivo especificado acima com o conteúdo a seguir (e lembre de dar permissão de execução ao mesmo):

Pronto! Agora você pode rodar aplicações do container que usem openGL sem precisar recorrer ao llvmpipe, que faria sua CPU chorar.

Configurando o suporte a áudio

Bom, já que vou usar o steam para jogar mesmo, então é melhor fazer o serviço completo e habilitar áudio também. Primeiro copie o arquivo de configuração do ambiente hospedeiro ~/.config/pulse/cookie para para o ambiente convidado. Então use o programa paprefs, vá na aba “Servidor de rede” e habilite a opção “Habilitar o acesso a dispositivos de som locais via rede”. O último passo é configurar a seguinte variável de ambiente (pode ser feito no arquivo .bashrc):

paprefs

Mais ideias

Essa seção é só uma desculpa para compartilhar esse post de muito tempo atrás sobre como uma empresa está usando a capacidade de ativação por socket do systemd para permitir alta densidade em seus servidores. Iniciar um container é bem rápido, bem mais rápido que iniciar uma máquina virtual. E usar um kernel único permite um gerenciamento de recursos mais inteligente do que temos, por exemplo, aqui (spoiler: é sobre hypervisor).

Na teoria, Linux containers permitem fazer um gerenciamento de recursos mais eficiente que máquinas virtuais. Servidores são grandes candidatos para se beneficiar de tal tecnologia. Isso não significa, entretanto, que máquinas virtuais perdem sua utilidade. Quando deseja-se utilizar um sistema operacional diferente (ou mesmo uma versão diferente do kernel) ou uma arquitetura diferente, por exemplo, containers não são melhores (nem sequer são uma opção).

Dois alvos que podem ser atacados usando containers são servidores e computadores de usuários. Em um você ganha desempenho e melhor compartilhamento de recursos da máquina física para os diferentes containers. No caso dos servidores poderia usar algo como o Docker. No outro (computadores de usuários) você ganha segurança e melhor isolamento ao rodar aplicações não-confiáveis e a solução poderia ser melhor que o gerenciamento de aplicações do Android. Para o problema de aplicações no computadores de usuários tem essa palestra legal do Lennart Poettering.

Um vídeo bem curto que mostra o Steam funcionando dentro do ambiente LXC:

http://vimeo.com/83444753

Referências adicionais

Além dos link encontrados em meio ao texto que você leu (assim espero), usei esse artigo do lwn.net como referência inicial.

EDIT (2014/01/06):

Seção “Mais ideias” estendida.

EDIT2 (2014/02/23):

Descobri o asciinema e coloquei algumas referências/links no meio do texto.

Preparing ArchLinux to compile powerpc targets

Recently I started working on PowerPC-related technologies and I needed to prepare an environment to start my studies/research and it’s not that difficult (but I recommend you to choose a book, because it’s going to take a lot of time), but I wanted to write a HOWTO for ArchLinux anyway.

qemu

qemu is an open source hypervisor that we will use to prepare our environment. All you need to do to install qemu under ArchLinux is run the following command:

After you have qemu installed, you need to install an operating system supporting PowerPC (just as you’d in a real machine). I wanna install ArchLinux, but looks like PowerPC support on Arch is dead, then I’ll go with Debian. The list of steps to follow is (1) create a virtual machine, (2) install a guest operating system on it and (3) configure the guest system to compile powerpc software.

To accomplish the first step, you need create a disk image and this can be done with the following command (where 20G is the size):

Put everything on the same folder and use the following script to start qemu:

Follow the usual Debian installation steps and change your script to boot from the HD (replace “-boot d” with “-boot c”). When I installed the system, the installer told me it couldn’t complete the installation of the bootloader, then I jumped this step and, for my surprise, the system booted up without my intervention.

Debian

The Debian comes with GNOME by default and is slow on an emulated system, then I recomend you to install the packages xfce4 and xfce4-goodies and replace GNOME.

Also, qemu is really slow to emulate the vga card, then I suggest you to install the package openssh-server and do most of your tasks via a ssh connection. You can redirect ports (good to access guest via ssh) from the host system to the guest system passing the -redir argument to the qemu-system-ppc command:

If you want to dig deeper, I suggest you to read this lenthy developerWorks article.

The next tutorial should be a cross-compilation guide to avoid all this middleware steps and part of it is already written, but I’m struggling to make the complete system work.

Instalando o Ubuntu em um ambiente chroot jail no Archlinux – parte 2

Continuando o artigo anterior, vou descrever como ficou a versão final de minha instalação Ubuntu dentro do ambiente chroot e mostrar as configurações que haviam ficado pendentes:

  • D-Bus
  • PulseAudio

Mudanças desde a última versão

Eu estava enfrentando alguns problemas com o debconf/apt-get, então resolvi pegar a instalação de minha máquina virtual e transferir para o ambiente chroot. Para transferir a partição, que estava em um arquivo vdi, reconhecido somente pelo VirtualBox, eu coloquei a ISO de um livecd na VM, e a partir da VM usei o comando (onde o remote.host era meu próprio ip):

NOTA: Antes de transferir a sua instalação Ubuntu, eu recomendo fortemente que instale todos os pacotes que você irá utilizar antes de transferir a partição. Isso vai lhe poupar bastante trabalho.

Para montar a imagem gerada com o comando anterior você pode usar o comando:

Você pode alterar o arquivo /etc/rc.d/chrootbuntu para que ele faça a montagem dessa imagem para você. Ele ficaria então assim:

Nova configuração do ambiente chroot

Um processo interessante é também copiar certos arquivos de configuração que recriem o ambiente Archlinux dentro do ambiente Ubuntu, como arquivos de usuários e grupos. Isso é importante porque em sistemas Linux, um processo qualquer herda as configurações de ambiente do processo-pai, e dessa forma o comando chroot herdará as configurações de ambiente do processo bash, que está rodando dentro do seu Archlinux. Quando iniciar o bash do sistema Ubuntu, ele utilizará os arquivos de configuração que estão inconsistentes com as variáveis de ambiente herdadas. Abaixo um simples teste que mostra sobre sobre o quê eu estou discutindo:

Você pode resolver o problema dessa inconsistência copiando arquivos importantes do sistema. Apenas execute os comandos abaixo:

Agora que o ambiente chroot está consistente com o ambiente Archlinux instalado, podemos também tornar o comando xhost mais seguro, restringindo os usuários com acesso ao seu servidor X:

D-Bus + PulseAudio

Para configurar uma única instância do D-Bus para todo o sistema, use os comandos abaixo antes de iniciar qualquer serviço D-Bus do ambiente chroot (lembrando que você também pode colocá-los no arquivo /etc/rc.d/chrootbuntu):

Para permitir que aplicativos que façam uso do PulseAudio reproduzam som, utilizaremos as capacidades do PulseAudio de transmitir som através da rede. Para tal, edite o arquivo /etc/pulse/default.pa (tanto no Ubuntu quanto no Archlinux), adicionando/descomentando a linha:

Essa mudança irá garantir que o seu PulseAudio carregue o módulo tcp durante a inicialização, mas caso ele já esteja rodando, abra o console do pulseaudio (usando o comando pacmd), e use a mesma linha anterior como um comando nesse console.

Agora que o módulo está carregado, precisamos autorizar o usuário do ambiente chroot a acessar o servidor PulseAudio rodando localmente. Para tal, copie o arquivo de cookie que está na sua pasta de usuário (~/.pulse-cookie) para a pasta dos usuários irão usar o PulseAudio dentro do ambiente chroot.

Para finalizar, crie/edite o arquivo /etc/asound.conf do Ubuntu adicionando o conteúdo a seguir:

Isso irá garantir que aplicações que façam uso diretamente do ALSA utilizem o PulseAudio.

Script facilitador

Um script que você pode colocar na sua pasta de usuário para automatizar a tarefa de configuração do X11 + PulseAudio é:

É isso.

EDIT:

Alguns programas (como o ROS, discutido na parte anterior do artigo), não irão funcionar corretamente se você configurou hostnames diferentes para a sua instalação Archlinux e sua instalação Ubuntu. Caso você tenha feito isso, não se desespere, basta editar o arquivo /etc/hosts e tudo vai funcionar normalmente.

EDIT2:

Alterei a linha:

Para:

Pois quando eu atualizei para o Linux 3.0 no Archlinux o comando antigo parou de funcionar.

EDIT3 (2014/02/10):

Hoje em dia eu não faria a abominação de copiar os arquivos da pasta /etc que definem usuários e grupos do ambiente hospedeiro para o ambiente convidado (ainda mais quando são baseados em distribuições completamente diferentes). Tal solução… tão vulgar… e pedindo para dores de cabeça no futuro. Só não apago o artigo, porque suas outras partes são úteis.

Hoje em dia eu só iria usar chroot para aplicações mínimas que não exigem comunicação com outros serviços do sistema. Se a aplicação precisar se comunicar com D-Bus, o Apache ou qualquer outro serviço do sistema, eu optaria por usar containers (chroot on steroids) no lugar. E a não ser que haja um meio fácil de atualizar a aplicação (e suas dependências) do chroot mínimo, eu acabaria optando por um ambiente completo no lugar de mínimo só para ter a facilidade de atualizar os pacotes facilmente (gerenciadores de pacotes ftw). Na verdade, eu provavelmente ainda acabaria optando por um container caso o ambiente convidado possuísse systemd, só para usufruir de suas funcionalidades legais como reiniciar serviços mortos, ativação por socket, monitoração de watchdog, interface unificada e bem documentada, …

E a “solução muito esperta” do D-Bus está com os dias contados com o pessoal querendo mover o D-Bus para o kernel.

Instalando o Ubuntu em um ambiente chroot jail no Archlinux

Devido ao fim de semestre na UFAL, não tive tempo para postar nada no mês passado, assim como não tive tempo também para trabalhar em meus próprios projetos.

Acho que esse é o meu primeiro post desde que meu blog foi agregado ao Planeta GNU/Linux Brasil e ao planeta Arch Linux Brasil.

Nesse post vou detalhar o processo de instalar um sistema Ubuntu aprisionado em um ambiente chroot gerenciado pelo Archlinux. Se você quiser ler mais sobre esse assunto recomendo a leitura das páginas:

Eu estou fazendo isso para trabalhar com o ROS no Archlinux sem a necessidade de usar gambiarras no sistema sem recorrer a uma VM e para colocar todos os pacotes não-livres como o skype dentro de um ambiente isolado. Alguns outros usos para um ambiente chroot podem ser:

  • Isolar aplicativos instáveis e inseguros
  • Rodar aplicativos 32-bit em ambientes 64-bit
  • Testar novos pacotes antes de instalá-los em um ambiente de produção
  • Rodar aplicativos mais velhos em sistemas mais modernos
  • Criar novos pacotes, permitindo um controle cuidadoso sobre as dependências que são instaladas

A arquitetura do ambiente

Com esse processo, pretendo criar um ambiente chroot que é separado em um daemon e um script a ser executado pelo usuário. O daemon vai preparar o ambiente chroot e adicionaremos ele a lista de daemons do sistema. O script a ser executado pelo usuário vai configurar o ambiente para que aplicativos usem o servidor X local e o servidor pulseaudio local.

Escolhi a versão LTS do Ubuntu porque é chato ficar gerenciado um ambiente chroot ou qualquer outro ambiente que não seja seu ambiente primário, então só vou precisar manter a cada 1,5 ano essa instalação.

Escolhi também a versão 32-bit do Ubuntu por conta de meu sistema ser 64-bit. Aí o que eu, dificilmente, não conseguir rodar nativamente aproveito para colocar no ambiente chroot.

Preparando o ambiente chroot

  1. Instale o pacote debootstrap
  2. Crie o diretório /srv/chroot/lucid
  3. Escolha um mirror aqui
  4. Execute o comando a seguir como root
  5. O meu comando ficou assim:
  6. Aguarde o processo de download e instalação terminar

Criando um daemon para o ambiente chroot

Crie o arquivo /etc/rc.d/chrootbuntu com o seguinte conteúdo:

Adicione permissão de execução ao arquivo com o comando:

Adicione-o na lista de DAEMONS no seu arquivo /etc/rc.conf para iniciá-lo junto com o sistema.

schroot

Schroot é uma ferramenta que permite usuários comuns rodarem comandos em ambientes chroot. Além disso, a ferramenta prepara o ambiente realizando algumas tarefas de configuração automaticamente, como montagens de sistemas de arquivos. Para instalá-la:

Após isso, adicione as seguintes linhas no arquivo /etc/schroot/schroot.conf:

Após isso você poderá abrir um shell no ambiente chroot usando seu usuário com o comando:

Se você tentar usar o comando anterior agora, deve ver o erro:

Isso ocorre porque o Archlinux e o Ubuntu usam sistemas de configuração de interfaces de redes diferentes, então a etapa de configuração de rede falha. Para evitar que a ferramenta schroot tente configurar a rede, remova o arquivo 20nssdatabases da pasta /etc/schroot/setup.d (recomendo movê-lo para uma pasta de backup).

Configurando o ambiente chroot

Para entrar no ambiente chroot sem usar o schroot, você pode usar, como root, o comando:

Nesse momento, a instalação do Ubuntu está crua, e muitos programas não vão funcionar corretamente. Um dos problemas nesse momento é configurar um locale, que no Ubuntu é feito automaticamente quando você instala algum language pack:

Precisamos também de um editor de texto para editar alguns arquivos de configuração:

Após isso, no ambiente chroot, edite o arquivo /etc/apt/sources.list para que ele fique com o seguinte conteúdo:

Então use o comando a seguir para atualizar a lista de pacotes:

Antes de prosseguir com a instalação de outros pacotes, é interessantes instalar os dois pacotes a seguir, pois o apt-get sozinho não é capaz de tratar da configuração dos pacotes.

Agora seria interessante criar um usuário comum dentro desse ambiente chroot, pois não é uma boa prática realizar todas as tarefas como root:

Configuração do X

Para rodar aplicativos gráficos que estão dentro do ambiente chroot, você precisa, a partir do seu ambiente Archlinux, em um terminal logado como seu usuário normal, rodar o seguinte comando:

Após isso qualquer aplicativo que você rode a partir do seu ambiente chroot vai usar automaticamente o servidor X em execução no seu sistema.

Bônus: ROS

ROS é o meta sistema operacional open source para robótica com o qual um grupo aqui na UFAL está trabalhando. Um dos problemas de instalá-lo no Archlinux, é que seus scripts apontam para o python mais recente, mas ele usa o python2, ocasionando muitos problemas, principalmente em distribuições rolling release como o Archlinux.

A situação do ROS no Ubuntu é mais estável, sendo a distribuição bem suportada oficialmente e ele pode ser instalado dentro do ambiente chroot que criamos normalmente, seguindo as instruções do site oficial:

http://www.ros.org/wiki/diamondback/Installation/Ubuntu

Próxima etapa

Muitos aplicativos gráficos costumam utilizar o dbus, então é recomendado que o dbus esteja configurado no ambiente chroot. Na próxima parte do artigo tentarei configurar o dbus e o pulseaudio para que os aplicativos do Ubuntu rodem suavemente dentro do Archllinux.

Fontes

Minhas fontes de consulta para criar esse ambiente e esse artigo foram:

Meu ambiente de desenvolvimento em 7 itens

Mesmo sem terem me incluído na brincadeira, até porque sou blogger novato, resolvi participar, pois a ideia é interessante.

Regras:

  1. Escreva sobre 7 itens de seu ambiente de trabalho – fale sobre qualquer ponto que quiser
  2. Indique de 3 a 5 pessoas para que possivelmente façam um artigo sobre seu ambiente

Meu ambiente

Começando pelo ambiente então.

Archlinux

Para responder com qual sistema eu me sinto mais confortável eu não preciso pensar muito para responder que é o GNU/Linux. Mas dentre as várias distribuições que eu testei (openSUSE, Debian, Ubuntu, Dreamlinux e alguns derivados irrelevantes), a única distribuição com a qual eu não tenho problemas sérios é a Archlinux.

O principal problema que eu enfrentava nas outras distribuições sempre acabava se resumindo ao gerenciamento de pacotes. Com o Ubuntu, por exemplo, eu sempre acaba configurando vários PPAs para ter as últimas versões disponíveis do VLC, Firefox, OpenOffice.org, ou mesmo instalando o binário fornecido pelos desenvolvedores, no caso do SDK do Qt, por exemplo. Essa prática sempre acabava me causando problemas. Tudo isso sem contar com o meu orgulho de programador ao ver que o meu sistema em si já era uma gambiarra!

Afinal, qual o ponto em ter um gerenciador de pacotes se no final você acaba gerenciando os pacotes por si próprio? A situação só se agravava com o passar do tempo, devido ao perfil de usuário no qual eu me encaixo. Um certo dia então, encontrei o Archlinux.

O problema dos repositórios e pacotes desatualizados foram resolvidos quando comecei a usar o Archlinux. O problema básico de versões velhas foi resolvido com o rolling release. Não há versões da distribuição, há versões dos pacotes, e se quiser um sistema atualizado é suficiente atualizar os pacotes. Para essa ideia ser viável, o sistema precisa de um gerenciador de pacotes robusto, e certamente posso afirmar isso sobre o pacman, pois a distro foi criada em 2002 e o gerenciador ainda está fazendo o que foi feito para fazer sem grandes dificuldades.

Outra vantagem do Arch é que eu finalmente posso instalar o zsnes no meu sistema 64-bit, pois o sistema possui um repositório multilib, com o propósito de facilitar tarefas como essa.

Ainda em repositórios, o Archlinux possui um grande repositório oficial, e o AUR, que sob a minha visão é um projeto que resolve o problema que os PPAs, do Ubuntu, deveria resolver. Graças a grande abrangência desses dois repositórios, e as políticas de gerenciamento adotadas pela comunidade, eu não mais preciso utilizar técnicas obscuras para instalar algum aplicativo.

Como se todas essas facilidades ainda não fossem o bastante, o pacman também é flexível o suficiente para que eu possa configurá-lo para utilizar o Aria2, ou algum outro, para efetuar o download dos pacotes.

MPD

MPD é um Media Player para quem não conhece. Primeiramente, é o único modo decente que encontrei de controlar um media player através do terminal. Mas uma escolha minha geralmente envolve mais que um motivo, e alguns dos outros motivos para escolher esse media player são os incontáveis modos de controlá-lo.

Tenho uma interface gráfica completa tradicional, uma interface para o firefox, uma interface web, uma interface para meu symbian (controlar seu media player no conforto do sofá é essencial =p) e ainda posso combinar o cliente linha de comando com vários outros aplicativos (associando atalhos de teclado no gnome ou no e17, por exemplo).

Além de toda a flexibilidade fornecida para controlar o MPD, posso configurar também para onde irá o som. As opções vão desde o sistema ALSA/PulseAudio (direto para a caixa de som), até streaming web via HTTP simples ou passando pelo Icecast. Adicionando o sistema JACK a combinação, as possibilidades são tentadoras.

Firefox

Antes não-tão-essencial, eu alternava entre o Chromium e o Firefox, pois para mim não havia muita diferença entre os dois. Mas a versão 4 do Firefox veio com um recurso que mudou minha opinião, o grupo de abas. Usando desse novo recurso, eu finalmente consigo navegar na web sem me perder, mesmo tendo em torno de 25 abas abertas durante a maior parte do tempo. Há um grande conjunto de pequenas mudanças que fizeram a diferença também, mas para mim essa funcionalidade é única.

Gmail

E o que seria de minha vida sem a google e seus produtos com seus níveis de qualidade que constantemente aumentam? Usando alguns recursos do labs (como várias listas de email, por exemplo) eu finalmente consegui organizar minhas tasks. E integrado com o Google Agenda, não preciso mais me lembrar de compromissos. São tantas funcionalidades. Não há nenhum produto igual.

Pidgin

Durante a realização de suas tasks você está vulnerável a sofrer stress, ainda mais quando você está trabalhando com tecnologias muito novas ou chatas. Um IM é essencial para diminuir o nível de stress e manter seu nível de produtividade. Já testei vários IMs, e apesar de não gostar do Pidgin, ele é o único que suporto.

Emacs

Costumo trabalhar com projetos escritos em diferentes linguagens, e não vi ainda uma IDE que seja suficiente para mim e suporte bem todas as linguagens com as quais trabalho. Diante dessa situação, um editor de textos avançado como o Vim ou o Emacs, é o que pode me ajudar. O primeiro que usei foi o Emacs, e eu até tentei esquecer o Emacs e usar o vi, mas eu me adaptei bem ao paradigma Emacs, e é ele que eu sei usar (e muito mal, se levar em consideração o tempo de uso e meu conhecimento).

Subversion

O sistema de versionamento que mais uso é o subversion. A maioria dos projetos em que eu trabalho o adota e ele é muito fácil de usar, principalmente quando tem uma interface web poderosa em conjunto. Fiz até algumas apresentações sobre ele e convenci várias pessoas a utilizá-lo, e isso no primeiro semestre de UFAL.

Minhas vítimas

Repasso a tarefa para:

%d blogueiros gostam disto: