Tecnologia / Blog /
Uma distro para todas dominar

Cléber

* Date: 2018-12-29 16:34:39 Esse artigo é, de certa forma, uma continuação do anterior, chamado "Pequena Investigação sobre Sistemas Operacionais". Você pode lê-lo antes desse, o que seria interessante, mas se quiser deixar para depois, tudo bem, já que é um tanto longo. Mas o que importa é que a história toda começa com uma combinação de fatores razoavelmente rara. Mais ou menos como um alinhamento planetário, sucedeu que tanto um *ímpeto pesquisatório* invadiu minha alma quanto a época era propícia: final de ano, folga no serviço, alguns dias livres em que o laptop pessoal não era necessariamente essencial para manter as coisas do trabalho rodando. Ou seja: eu poderia muito bem gastar um tempo "pesquisando" na máquina. Como eu disse antes, eu tive contato com a "filosofia *suckless*", que evoca "**simplicidade, clareza e frugalidade**, recentemente, e isso foi como uma soprada de secador de cabelo no carvão da churrasqueira da minha alma (olha só que metáfora linda e exclusiva, entendida por apenas alguns poucos bem-aventurados). É fato: eu tenho uma queda por "simplicidade, clareza e frugalidade". As artes podem ser complexas e rebuscadas quando necessário para se atingir a beleza, mas em um mundo que mistura arte e engenharia, como o da computação e desenvolvimento de software, há uma beleza intrínseca à simplicidade que, de alguma forma, é absolutamente mais sublime que qualquer monstruosidade rebuscada e complexa que qualquer um possa um dia construir. # O pingo d'água Ainda influenciado pelo *suckless*, comecei a tentar "emagrecer" o MX Linux que estava instalado no meu laptop. Porque, afinal, há certas coisas que eu absolutamente não preciso e não uso, como **bluetoothd**, **ModemManager** e, especialmente, o que foi **o pingo d'água** que me levou a abandonar esse mundo das "*distros-tudo pronto*", o tal do **ssh-agent**. Já tem muitos anos que eu usava o **Fluxbox** como gerenciador de janelas e andava bem feliz com ele. Afinal, ele é leve, extremamente customizável, é configurado via arquivos de texto muito simples e tem um uso de memória quase desprezível. Logo, mandando um `ps aux` no terminal, eu esperava ver uma entrada dizendo, simplesmente, `/usr/bin/fluxbox`. Mas o que aparecia na tela era um horrendo `dbus-launch ssh-agent /usb/bin/fluxbox`. dbus-launch? ssh-agent??? Que diabos? ## ssh-agent e outros Eu sou usuário assíduo do `openssh`, mas não fazia ideia do propósito desse tal de `ssh-agent`. Acabei descobrindo que tem algo a ver com salvar chaves em memória, coisa que, na prática, eu nunca precisei e não acho que precisarei. E, além disso, havia esse tal de `dbus-launch`. Esses dois e mais outras infindáveis "coisinhas" que ficavam rodando na máquina sem haver real necessidade. A conexão com a internet era gerenciada via `NetworkManager`, mas, sinceramente, toda vez que esse chato fez aquilo que parece ser seu propósito, foi contra a minha vontade e serviu só para me atrapalhar. # Aviso! O que descreverei a seguir é um conjunto de customizações que **eu** fiz para atender às **minhas** necessidades e vontades. Não é nada de outro mundo, mas certamente não é para os fracos de coração. Além disso, repito o ditado: "cada escolha, uma renúncia". Eu estou renunciando uma porção de comodidades em nome de **controle** e de um ideal filosófico que considero nobre, belo e correto. Talvez você não pense como eu. Talvez você não **possa** abrir mão de certas "comodidades". Afinal, como eu disse no começo, houve uma combinação de fatores que me permitiu "perder tempo" com tudo isso. Então, que fique o aviso. Eu conto aqui as coisas que fiz mais "por propósito acadêmico" do que como uma tentativa de "evangelizar" outras pessoas para fazerem o mesmo. ## Coisas que não "funcionam" mais ### automount de celular Android Coisa que eu já não fazia questão, mesmo. Prefiro usar um `mtpfs` e montar, via FUSE, o celular como um sistema de arquivos local do que me obrigar a abrir um `thunar` (gerenciador de arquivos gráfico) e gerenciar arquivos usando o mouse. É possível fazer "automount" não somente de `MTP` (Android e outros dispositivos móveis), mas de praticamente qualquer coisa. Se mais pessoas usassem meu laptop, talvez eu gastasse energia com isso. Como não é o caso, então prefiro resolver tudo "na unha". ### Troca de interface de rede automática Estudando sobre como conectar o laptop numa rede sem fio, acabei criando o projetinho ["wifi.sh"](https://github.com/cleberzavadniak/wifi.sh). Acontece que, quando você elimina o `NetworkManager`, acaba perdendo essa funcionalidade de, por exemplo, conectar-se à rede com fios tão logo uma esteja disponível. É preciso ter algum conhecimento de configuração de redes no Linux para conseguir se virar por conta própria (no mínimo, saber o básico do comando `ip`). ### Carregamento automático de módulos do kernel Eu tive que configurar manualmente o carregamento dos módulos responsáveis pela minha placa de rede sem fio, do ipv6 (o exemplo mais contundente, talvez, de *overengineering* que temos, mas é o que temos, atualmente) e do áudio. Fazer isso foi o que mais me lembrou da sensação de instalar e configurar o **Slackware** lá pelos idos de 2005. Na época em que "Slack" era sinônimo da distribuição, não do IRC-dos-caras-legais... ### Re-detecção do mouse e trackpad Outra coisa que me fez sentir "lá pelos idos de 2005": eu uso, em casa, um mouse com fio e, usando o Xorg, caso eu o desconecte do laptop e conecte-o novamente, ele simplesmente para de funcionar e eu sou obrigado a reiniciar o X. Seria menos chato se o *trackpad* funcionasse. Mas não funciona, por enquanto. Mas isso é coisa que eu logo deixo redondo, pois não é tão complicado assim. ## Coisas que funcionam ### Áudio No passado eu já tive dificuldades em fazer certos computadores emitirem sons que não parecessem rugidos monstruosos ou mesmo qualquer som que fosse. Mas dessa vez eu simplesmente carreguei alguns módulos e tudo funcionou muito bem. ### Rede sem fio Minha placa de rede é uma `rtl8723be` (Realtek) e foi também meramente questão de carregar o módulo certo para ela funcionar. ### Tudo o mais Até agora não senti falta de nada. :) # Camadas A ideia principal do meu *setup* é dividir o sistema em camadas razoavelmente bem isoladas, cada uma com objetivos de existência muito claros. ``` +------------------ | Machine | | +-------------------+ | | Alpine base | Only essential packages | | | | | +--------------+ | | | | Alpine main | | Shell oriented, some comfort, root only (no udev) | | +--------------+ | | | | | | +--------------+ | | | | Funtoo | | User desktop, suckless (+eudev, -dbus, -systemd, -gconf, -dconf) | | +--------------+ | | | | | | +--------------+ | | | | Void | | Dirty as needed (dbus, gconf, dconf, etc.) | | +--------------+ | | | | | | +--------------+ | | | | Ubuntu (lxc) | | Simply awful... | | +--------------+ | | +-------------------+ +------------------ ``` ## Partições Meu plano original era ter **oito** partições no disco rígido, mas acabei criando **nove** meio que por uma sequencia de acidentes e, sinceramente, estou achando melhor que seja assim mesmo. A não ser que você tenha bons motivos para fazer o contrário, fuja do particionamento tradicional "GPT". Com ele você só poderia criar quatro partições "primárias". O que te obrigaria, caso quisesse criar nove partições, a criar **três** primárias, uma "extendida" e seis "virtuais". Isso funcionou bem por muito tempo, mas olhando atualmente, é simplesmente muito esquisito. Usando o sistema "UEFI" você simplesmente tem nove partições e pronto, sem precisar se preocupar com "primárias" ou "virtuais". Uma dica importante é **não ligar muito para a numeração das partições**. Como eu já tinha algumas prontas, a ordem numérica não ficou exatamente como eu queria, mas isso não faz muita diferença. A única coisa que eu faço questão é ter a partição "EFI" em `sda1` e "/boot" em `sda2`. O disco rígido do laptop, de 1TB, acabou particionado assim: * sda1: EFI (vfat) : 524M * sda2: /boot : 150M * sda3: /home : 195G * sda4: linux swap : 8.1G * sda5: Ubuntu : 9.8G * sda6: /mnt/archives : 235GB * sda7: Alpine base : 1.2G * sda8: /mnt/vms : 175G * sda9: /mnt/data : 306.2G Eu não pretendia criar uma partição "/mnt/data", mas entre tê-la e ter que **mover** minha "/mnt/archives", que é onde meus dados "preciosos" ficam armazenados, acabei preferindo a primeira opção. ### EFI É onde o sistema busca os "bootadores.x64". Eu não pretendia deixá-la tão grande, mas fiquei com preguiça de entender o jeito certo de redimensioná-la (esses sistemas "FAT" são meio bizarrinhos e eu, sinceramente, não gosto muito de mexer com essas tecnologias propensas a erros medonhos como se fossem um "ext3" da vida). ### /boot É onde ficam os kernels e os "initial ramdisks". Eu já tive situações em que precisei de muito espaço, mas como atualmente a ideia é ter um, no máximo dois kernels instalados lá, 150MB tá de bom tamanho. Poderia até ser menos, mas como o HD é grande, botar um pouco mais de espaço não custam muito. ### /home versus /mnt/archives Aqui eu deixo uma pequena crítica ao "mundo Unix": o diretório /home é um lugar muito bagunçado. Mistura-se as minhas fotos de família com configurações de programas que eu já não uso faz anos com as bibliotecas baixadas pelo `pip` ou pelo `npm`. **Sempre** que estou fazendo um backup eu acabo vendo algum diretório **bizarro** que é responsável por quase metade do espaço em disco gasto, como é o caso do `.npm` ou `.pyenv`. Eu não quero fazer backup dos módulos baixados pelo `pyenv`, nem dos do `npm`. Eles não são importantes e podem ser baixados novamente a qualquer hora. E o resultado dessa mistureba toda é que o que poderia ser um backup da partição toda acaba virando um festival de "cherrypick" no qual você tem que ficar escolhendo o que vai para o backup e o que absolutamente não é importante e acabaria só gastando o teu tempo (e essas coisas que vão assim "de graça" consomem **bastante** tempo). Por isso eu separo "**fisicamente**" meus arquivos importantes: eles vão parar no `/mnt/archives` ao invés de ficar no meu `/home`. Como resultado, o `/home` tem importância secundária: ter que reconfigurar o Firefox é chato, mas é menos do que perder todos os vídeos dos ensaios da minha antiga banda ou as minhas fotos de família. (Mas, claro, de qualquer forma, eu mantenho backup de tudo em outra máquina.) Ademais, nessa vida de instalar novas distros de quando em quando eu já me deparei com instaladores que **apagam o seu diretório home** sem te avisar. Ou seja: ainda outro motivo para separar uma coisa da outra. (Outra recomendação minha é **nunca** montar o `/home` durante a instalação de uma distro desconhecida, mas sempre deixar para fazer isso como o próximo passo **após** o sistema já estar instalado.) ### Ubuntu / Mint Esse é meu sistema de emergência. Há horas nessa vida em que é bom ter algo em mãos em que tudo simplesmente funcione, não importa qual gambiarra um exército de programadores malucos fez para chegar no resultado. ### Alpine base A partição de "bootstrap". Falarei mais sobre o Alpine adiante. ### VMs Aqui é onde vivem os **outros** sistemas operacionais, tanto das outras camadas, como o Funtoo, quanto aqueles que quero testar. O nome "VMs" vem de "máquinas virtuais", mas não necessariamente indica que rodarei tudo em algum emulador/hypervisor. As distros das outras camadas, por exemplo, rodam perfeitamente bem com um simples `chroot`. ### data Aqui pretendo salvar tanto os diretórios gigantes que habitam normalmente meu `/home`, como os já citados `.pyenv` e `.npm`, quanto dados que geralmente vão no `/var/lib` das distros, como os dados em si dos SGBDs. Eu faço questão de separar porque quero que os "root filesystems" das "VMs" sejam o mais "dispensáveis" possível, ou seja: se a qualquer momento eu quiser simplesmente mandar uma "VM" pro espaço, eu quero poder fazê-lo sem muita preocupação. Outras coisas, como meu `/etc/hosts` (que é um conjunto cuidadosamente curado de diversos hosts bloqueados, especialmente domínios de propagandas, trackers e vídeos com autoplay) também serão salvas aqui. # Alpine Linux Não lembro exatamente o motivo, mas acabei testando, num "chroot" local, antes de começar esse plano mirabolante, o tal do "Alpine Linux". Lendo algumas discussões na internet, especialmente nos comentários do DistroWatch e do Reddit, percebi que muito se falava sobre "Alpine é bom para servidores, mas ruim para desktop". E uma média muito alta no DistroWatch. Ou seja: bem o que eu precisava. Afinal, também li muito que "uma distro leve boa para desktop é o Void". E, como eu já havia percebido, o Void **não é** uma boa "distro principal" para mim, já que eu sacrificaria **controle** em nome de velocidade, coisa que não é exatamente meu objetivo primário. O Alpine é uma distro minimalista e geralmente usada em **containers**, já que sua versão "chroot/container" ocupa, segundo dizem, menos que 20MB. Assim, sendo uma distro extremamente leve, **sem** foco [primário] em *desktop* e usada por muita gente ao redor do mundo, seja em containers, seja em roteadores, firewalls e outros tipos de equipamentos, pareceu-me que seria o ideal para constituir a camada "base" da "arquitetura" que montei na minha cabeça. Afinal, não é bem o tipo de distriuição que os mantenedores podem, num estalar de dedos, "mudar tudo do dia pra noite". ## base O espaço "apertado" da "distro bootstrap" (Alpine) serve justamente para me lembrar do propósito dela: servir de "bootstrap" das outras camadas. Basicamente, eu preciso que o hardware funcione e preciso de um shell, tanto para realizar "tarefas administrativas" de vez em quanto quanto para deixar certas funcionalidades rodando, conforme explicarei mais adiante. Aqui, **nada de comodidade**, mesmo no shell. Sem bash, sem zsh, sem nem mesmo a partição "/home" montada. Na "base" carrega-se os módulos, configura-se a rede e o resto é outra camada que fará. Nem swap montamos aqui. O objetivo dessa camada é **estabilidade**. Quanto menos firula, melhor. Outra responsabilidade dessa camada é manter o **gerenciador de boot** funcionando. No caso, escolhi o **Grub2**, com o qual sou mais familiar e, sinceramente, me parece funcionar de um jeito até mais simples que outros gerenciadores ditos "minimalistas". ## grub2 + UEFI Desde já, darei uma dica **vital** para que você, caso queira usar o grub2, consiga instalá-lo na partição EFI do seu HD: instale o pacote `efitools` **do repositório "testing"**! Para isso: 1- Dê uma olhada em `/etc/apk/repositories`. 2- Use uma das entradas como parâmetro para `-X` do comando `apk`, mas **substitua "main" por "testing"**. (Pelo menos isso é o que eu precisei fazer em dezembro de 2018, caro viajante temporal.) ## Velocidade O tempo de "grub até login" é **muito** curto: 12 segundos. Considerando que não gastei tempo algum buscando otimizar nada, para mim isso está excelente. Interessante comentar: o script "networking" do `init.d` tinha a mania feia de cuspir texto (especialmente do `dhcpcd`) por cima do prompt de login. Eu tive que editá-lo, chamar a função `start` por outro nome, e chamá-la por uma nova função `start` que redireciona **todo** o "output" para `/var/log/networking`. ## Instalação O Alpine não tem tanto foco em ser instalado lado a lado com outra distro em um laptop comum. Por isso ele pode ser meio assustador em alguns casos, especialmente no script **setup-disk**. Caso você esteja instalando o Alpine via `chroot`, como eu fiz, minha recomendação é que vocè **nunca rode nem o setup-disk nem o setup-alpine**. É melhor rodar os outros "setup-\*" na unha e deixar as coisas mais "sensíveis" para você mesmo fazer. Talvez o `setup-disk` nem faça tão mal, mas ele comete o pecado de **não ser absolutamente claro a respeito do que está fazendo**. ## Pacotes Os pacotes do Alpine me lembram **muito** os pacotes do **Slackware**, pois não passam de árvores de arquivos/diretórios compactadas que são descompactadas na raiz do sistema (ou algum outro lugar de sua escolha) no momento da instalação. ## Configuração Configurar o Alpine é muito mais simples que configurar, por exemplo, o **Gentoo**, embora ter experiência com este ajude muito. Eu cheguei a usar o Arch Linux por um tempo, e o Alpine ainda é mais simples. Talvez só o próprio Slackware consiga chegar a um empate nesse quesito, mas o Alpine leva muita vantagem pelo fato de que ele é projetado para funcionar bem com *setups* **mínimos**, ao contrário do Slackware, que por definição é uma distro projetada para ser instalada **por completo**. # Alpine main O propósito dessa camada **ainda** é "tarefas administrativas", mas como eu já tenho uma focada em estabilidade, aqui eu posso dar-me ao luxo de ter algum **conforto**. Aqui eu instalo um shell melhor que o `sh` e configuro algumas coisinhas que tornam o sistema mais amigável. Entretanto, aqui **não temos o `/home` montado automaticamente**. Essa camada ainda não é o "desktop" de ninguém, mas somente um local mais "mentalmente são" para se executar tarefas administrativas, inclusive tendo muito mais espaço de armazenamento para a instalação de pacotes. Também é proibido instalar um "display manager": Xorg/X11/Wayland/whatever. Essa camada é apenas uma "camada de comodidade", muito mais semelhante à "Alpine base" do que a um "desktop". # Funtoo main Aqui é onde boa parte do **desktop** reside: temos usuários normais, temos Xorg, temos pacotes diversos instalados. Eu tenho feito questão de usar o que o Funtoo tem de melhor, que é o **controle**, e deixar essa camada o mais "suckless" possível: eu mascaro (ou seja: impeço que o sistema instale, sob qualquer circunstância) dbus, systemd, gconf, dconf e o que mais eu achar que é um pedaço de software podre. No meio tempo entre a instalação do sistema base (untar do "stage3" e a devida configuração do "chroot") e deixar bem redondas as configurações do Portage (USE flags globais, masks, USE flags de pacotes específicos), o Fluxbox, meu gerenciador de janelas companheiro de muitos anos, ficava pedindo a instalação de um monte de dependências que eu absolutamente não queria ter nessa camada. Como resultado, fui à busca de um gerenciador de janelas mais simples e acabei encontrando um que me agradou bastante, o **spectrwm** (eu me bati com o nome por um tempo até entender que a ideia é chamar de "spectrum", não "spectr wm"). Eu achava que tinha alguma experiência usando gerenciadores de janelas "tilerizados" (que ajustam as janelas de acordo com padrões ao invés de deixá-las todas "soltas" na tela) por ter usado o `awesome` por algum tempo, mas descobri que usar `awesome` e usar `spectrwm` são experiências **completamente** diferentes. Nessa camada eu tenho liberdade de instalar bastante coisa, mas evito fazer dela "um outro Ubuntu". Pacotes que eu considero "sujos" absolutamente não entram aqui, o que acaba deixando certos pesos-pesados de fora, especialmente **Firefox** e **GIMP**. No caso deles, eu preciso de outra camada na qual eu permita sujeira. # Void Eu cheguei a pensar em ter uma "camada suja" com o **Ubuntu** rodando, mas a verdade é que ele se comporta **muito mal** em ambientes *chroot*. Já o Void, assim como Alpine e Funtoo/Gentoo, funciona sem problema algum. Assim, usando Void ao invés de Ubuntu, além de uma distro **muito** mais leve e com um gerenciador de pacotes muito mais rápido, eu evito a necessidade de usar um **lxc** só para rodar o Ubuntu. Caso eu precise, eventualmente, de algum software exclusivo do Ubuntu, provavelmente usarei o **Docker**. Estou usando o Void baseado na `musl-libc`. Mesmo que esteja rodando via *chroot*, posso dizer que é **bem** rápido, já que eu tenho muito tempo lidando com `apt-get` e é bem perceptível que o `xbps` (gerenciador de pacotes do Void) é muito, mas **muito** mais ágil em qualquer operação **exceto download dos pacotes**, já que o Void, pelo menos nesse momento, é meio fraco de *mirrors*... # Login em chroot Primeiramente, é importante salientar que eu não estou usando um "dm", que são aqueles programas que oferecem uma tela gráfica de login. **Eu faço login direto no terminal** e inicio o Xorg via `startx` -- **quando** inicio o Xorg. É curioso como ter um sistema ultra-leve faz com que certos costumes, como o de deixar os programas mais usados sempre abertos, desapareçam. Alie isso ao fato de que eu tenho **usado o elinks mais que o Firefox** e logo se vê por que o Xorg acabou tornando-se algo mais opcional para mim. Deixando tudo como estava, para logar como meu usuário eu teria que * Iniciar o sistema. * Logar como root no Alpine base. * `chroot /mnt/vms/funtoo-main/ /bin/bash` * `sudo su cleber` Para um uso normal, **é muito "root"** num fluxo que só envolve um usuário. Tudo bem que um desktop tem riscos de segurança menos críticos que um servidor exposto à web ou mesmo com vários usuários, mas também não precisamos exagerar. Além do que, é **muito pouco prático**. E, como bom *sysadmin*, é necessário cortar repetições. Logo, configurei os seguintes terminais virtuais: * tty1: login no Funtoo * tty2: login no Alpine base * tty3: login no Alpine base Não cheguei a configurar um login no "Alpine main", ainda, mas é mais porque eu não cheguei a precisar disso o suficiente. De qualquer maneira, é muito fácil de fazer isso futuramente. ## getty Para configurar um login em *chroot* é preciso entender como funciona o `getty`. Da página de manual, ficamos sabendo que o `getty` "abre uma porta TTY, pede um nome de login e chama o comando login". Pedir o nome de usuário é algo que ainda queremos. Só o que precisamos mudar é o programa "login", que, ao invés de ser chamado diretamente da raiz, precisará ser "chrooteado" para dentro do sistema de arquivos do Funtoo. Para isso, criei um script bem simples, em `/root/funtoo-login,sh`: ```bash #!/bin/sh exec chroot /mnt/vms/funtoo-main/rootfs /bin/login $* ``` Depois editei o `/etc/inittab`, colocando no `tty1` a seguinte entrada: ```bash tty1::respawn:/sbin/getty -l /root/funtoo-login.sh 38400 tty1 ``` E assim, a partir do próximo reboot, o terminal virtual 1 (o primeiro a ser mostrado e acessível, em outros momentos, via ctrl+alt+f1) me permite logar diretamente no Funtoo, enquanto os outros dois (ou quantos mais forem) me permitem logar no Alpine base. Eventualmente o `tty2` acabará sendo um login direto no "Alpine main". # Rodando comandos como usuário em outras camadas Meu shell e gerenciador de janelas são executados no "Funtoo main", mas o Firefox está instalado no Void. Para acessá-lo sem ter que ficar mandando "sudo" para cima e para baixo, faço uso de uma excelente ferramenta, o **firejail**. Inicialmente criado para manter o Firefox numa "caixa de areia" bem isolada, o projeto serve, na prática, quase como um "lxc instantâneo", já que permite fazer uso de maneira muito simples de muitas funcionalidades típicas de containers, como limites de uso de recursos, "seccomp", *chroot* e até *overlayfs*. O meu comando para chamar o Firefox é o seguinte: ```bash #!/bin/bash exec firejail --noprofile --chroot=/mnt/vms/void/rootfs \ /usr/bin/firefox \ -ProfileManager \ -no-remote ``` (Do "-ProfileManager" em diante você pode não precisar, caso não faça uso dos perfis do Firefox como eu.) ## Funtoo para Void Inicialmente o sistema era composto de apenas duas camadas: "Alpine base" primeiro e todo o resto sobre ela. Mas como meu desktop é no Funtoo, eu preciso que os pontos de montagem do Void **sejam relativos ao Funtoo**. Então eu criei um script que faz todas as montagens da segunda camada (Alpine main, Funtoo e Void) e em seguida faz as montagens do Void em relação ao Funtoo. É interessante fazer essas experiências porque certos assuntos ficam mais claros na cabeça. Por exemplo: os pontos de montagem são únicos em seus respectivos caminhos. Por exemplo: se eu monto o `sda8` (vms) em um diretório que está dentro do próprio `/mnt/vms`, não significa que farei algum tipo de "recursão infinita". Um `ls /mnt/vms/void/rootfs/mnt/vms/void/roots/mnt/vms` não me retornará nenhum item (a não ser que eu faça uma terceira montagem, ou seja, que eu **propositadamente** faça com que esse caminho, que é único, receba uma montagem). # Resultados * Grub-até-login em 12 segundos. * O "load" da CPU gira em torno de **0.5**. * Estou usando `spectrwm` e estou gostando. * Uso muito menos o Firefox e muito mais o **elinks**. * Tenho um sistema em que muito dificilmente precisarei de um "pendrive de boot". * **NADA DE XML** como formato de arquivo de configuração do sistema nas distros principais. :) Num próximo artigo falarei mais sobre o `spectrwm` e outras coisas que foram citadas muito rapidamente neste. Até lá!

Curti

52 visitantes curtiram esse Item.

Anterior: Pequena Investigação sobre Sistemas Operacionais | Próximo: O Medium e a Estrela da Morte