*Nota: esse artigo foi originalmente escrito pra Revista Espírito Livre, mas como a edição não saiu estou postando aqui.
Olá leitores da Revista Espírito Livre. Eu venho do futuro pra falar sobre os 30 anos de Linux. Futuro muitos anos à frente? Sinto mas estou apenas algumas horas adiantado devido ao timezone em que vivo. Mas tenho um certo prazer em dizer que celebrei a chegada do ano novo antes que todo mundo no Brasil, e avisando o que os aguarda do futuro (geralmente nada). E vamos ser sinceros: no mundo de hoje com tanta gente acreditando em terra plana, rejeitando vacinas e tomando cloroquina, dizer que venho do futuro é até uma licença poética aceitável.
Mas vamos voltar ao assunto do artigo: Linux. E seus 30 anos de vida. Foi uma comemoração bem moderada, sem grandes festas, sem bolo pra comemorar, e nenhuma meetup organizada. Ao menos por aqui. Talvez a culpa fosse da pandemia. Talvez fosse porque Linux já é tão comum e seu uso é diário, o que não nos faz mais sentir que seu aniversário é uma data especial. Mas são 30 anos desde que um estudante finlandês tentou escrever um minix melhor que o minix, um sistema operacional Unix para estudantes, e achou que nunca seria tão grande quanto o projeto GNU.
Não, não vou entrar na polêmica de quem é maior que quem entre GNU e Linux. Ambos têm seus méritos e são gigantes. E não estaríamos onde estamos sem eles. O projeto GNU já completou 38 anos também no dia 27 de setembro, mas o artigo é sobre Linux. Então deixo meus parabéns ao projeto GNU mas tenho de dizer que mesmo o sistema operacional mais comum que usamos pelas distros sendo um GNU/Linux, é Linux que o chamamos. Isso começou desde muito tempo atrás e duvido que mude algum dia. Alguns podem insistir em chamar de GNU/Linux, mas se até mesmo o Debian mudou de Debian GNU/Linux pra simplesmente Debian, que diremos de Linux além, é claro, de apenas Linux? Nomes curtos têm tendência a ficar melhores e as pessoas relacionam-se com isso mais facilmente.
Parte dessa tradição de denominação veio como herança de como eram os sistemas Unix nos princípios dos tempos, ou anos 70 em Unix time. Primeiro existiu o Unix da AT&T, em seguida surgiu uma melhoria desse que ficou conhecida como BSD, de Berkeley. E assim foi por quase 10 anos. O Unix BSD era basicamente o mesmo Unix, mas com drivers, ferramentas, scripts e até sistema de boot de Berkeley. E era o sistema operacional completo, com kernel, bibliotecas, editores, shell, etc. Mesmo os sistemas que surgiram da compra da licença do Unix da AT&T, como SunOS da Sun – atual Oracle, eram sistemas operacionais completos mas com nomes curtos como SunOS, HP-UX, SCO, Xenix, etc.
Quando o bom doutor, Richard Stallman, teve a epifania de criar um sistema operacional totalmente livre, o sistema operacional GNU – pra poder dizer que GNU não era Unix (GNU is Not Unix), nunca pensou em criar tudo de forma coesa. Ele começou da forma simples e em partes. Primeiro as ferramentas: editor (se bem que emacs é mais uma religião que editor mas isso é assunto pra outro artigo bem mais longo que esse), compilador, shell, etc. Mas tudo era separado em seu repositório e era necessário baixar os fontes e compilar sua versão usável. Então nunca houve uma identidade de sistema operacional GNU. Era a biblioteca sunsite com ferramentas GNU. Até surgir o Linux e permitir criar um sistema operacional completo. Claro que pra isso foram necessários os surgimentos das distros, um encurtamento para distribuições, que empacotavam o Linux com GNU e distribuíam como sistema operacional.
E Linux nasceu como um kernel, como já descrevi antes no “um minix melhor que o minix”, mesmo que Tannenbaum discordasse disso, e cresceu tanto em linhas quanto em contribuidores e até mesmo em ecossistema. Hoje em dia Linux é um projeto, uma fundação. E abrange de redes à containers com OCI, Open Container Iniciative. E apesar de ter nascido pra rodar software da GNU como bash e ser compilado com GCC, hoje em dia já roda em sistemas sem nada da GNU como Alpine e Android. E compila com o llvm. Não totalmente como com GCC, mas é um trabalho em andamento e deve em algum momento tornar o Linux compilável com qualquer compilador C. Isso sem comentar o suporte à linguagem rust, que poderá talvez nos próximo 10 anos virar boa parte do código do kernel. Talvez até a maior parte dele. Quem sabe?
Desses 30 anos eu já comentei sobre os surgimento das distros. Falta escrever sobre o desaparecimento delas. Atualmente o site distrowatch, famoso por enumerar as distros que surgiam, parece mais um obituário. A grande maioria das distros que surgiram também sumiram. Não que alguém vá sentir falta da Bieber Linux ou da Hanna Montana Linux, mas sei de gente que até hoje chora a perda do – um momento pra respirar e segurar a náusea – kurumin. A maioria dessas distros recebeu a alcunha carinhosa no Brasil de REFISEFUQUIs. Aqui peço a ajuda ao amigo Fábio Benedito pra descrever o que são:
As REFISEQUIs mostraram um lado interessante sobre a liberdade do software livre: cada um podia e ainda pode fazer um fork de alguma distro e criar a sua própria. Ao contrário das distros que contavam com legiões de voluntários ou funcionários, dependendo se fossem empresas ou projetos voluntários como Fedora e Debian, as REFISEFUQUIs eram batalhas de um soldado só. Talvez dois. Mas não muito mais que isso. Conseguiam fazer o primeiro release, o segundo, então o... o... o... acabava o gás. Talvez algumas tenham ido um pouco mais longe que isso, mas ninguém sobrevive ao tempo sem organização e principalmente mãos pra ajudar a manter tudo funcionando. Talvez o propósito fosse somente ter seu sistema listado na distrowatch. Nesse caso tenho de admitir que a missão foi cumprida. Amigos, amigos, negócios à parte.
E o que dizer das empresas? Nesses 30 anos muitas delas surgiram pra levar o Linux pra todos como principal sistema operacional do desktop. Inclusive com a versão tupiniquim com a Conectiva. E eram muitas. Infelizmente o cenário atual conta com apenas algumas delas. As que não faliram sofreram um processo de compra ou fusão. E eventualmente faliram. Talvez a venda de software gratuito não fosse tão bom negócio assim? A venda da Red Hat pra IBM por mais de 34 bilhões de dólares dizem o contrário. O que faltou então? Talvez menos geeks programadores e mais pessoas de negócios gerenciando a empresa? Talvez. A verdade é que muita coisa foi feita sem muito planejamento e só imaginando bastasse o software ter licença GPL ou qualquer outra livre e seria o suficiente pra empresa sobreviver. Infelizmente a realidade mostrou que não era bem isso.
E não só de dramas empresariais viveu o Linux nesses 30 anos. Teve também o caso da vira-casaca Caldera Open Linux, que comprou o que sobrou da SCO e aplicou um processo por roubo de propriedade intelectual contra o Linux. O caso ficou anos num tribunal e finalmente teve um fim. Os gestores da massa falida da empresa, que por motivos óbvios não conseguiu sobreviver no negócio, fechou um acordo muito bom de mais de 14 milhões de dólares com a... IBM!? Não me perguntem o porquê da IBM ter sido envolvida em suposto roubo de propriedade intelectual do Linux, mas no fim ela comprou o que sobrou de patentes e propriedade intelectual e encerrou o assunto.
Outro caso de tribunal nesses 30 anos de Linux que ficou muito famoso foi a prisão de Hans Reiser, criador do filesystem reiserfs, um dos primeiros filesystems com journaling no Linux e que eu pessoalmente cheguei a usar, acusado de assassinato. Não que sua prisão tenha alguma relação com Linux. Pelo contrário. Mas foi algo que impactou a direção dos filesystems em Linux, que estavam em suas infâncias no mundo journalling. Depois de sua prisão eu fui movido por, digamos, forças superiores a usar o XFS que foi doado pela SGI ao Linux. E até hoje é meu filesystem predileto, junto com LVM.
Outro drama vivido na lista do kernel durante esses 30 anos foi o eventual sumisso do próprio Linus Torvalds seguido da introdução de um código de conduta,vonde ele mesmo aceitava que tinha um comportamento tóxico e que precisa fazer terapia para endereçar seus problemas de uma melhor maneira. Não faltou gritaria em relação ao código de conduta com ataques dizendo que o mesmo iria coibir a participação das pessoas no desenvolvimento do kernel. Atualmente ninguém questiona o quão benéfico foi esse código de conduta, assim como quão tarde veio a ser adotado. E, claro, ainda há quem diga que ele motivou muita gente a não participar mais do desenvolvimento. Quantos? Esse será um dado que nunca veremos.
E ao longo desses 30 anos do Linux vimos também a grande batalha dos sistemas de inits, onde systemd saiu como vencedor e upstart virou lembrança. De todos os males ditos sobre o systemd na época, poucos realmente aconteceram, se é que aconteceram. E justiça seja feita: systemd é muito, mas muito mais que um mero sistema de init.
Claro que algumas distros seguem longe do systemd, como se isso fosse algum certificado de pureza. Mas nada que abale a realidade de que systemd funciona, vai muito bem obrigado, e trouxe flexibilidade e robustez ao Linux. Se antes precisávamos de gambiarras pra monitorar se um daemon não tinha dado crash e fechado inesperadamente, agora apenas temos o systemd lá monitorando e garantindo tudo funcionando. Ou quase. Claro que aparecem uns problemas aqui e ali, mas nada que negue o fato de que systemd melhorou muito a forma de como Linux tem seus daemons rodando.
crond? Coisa do passado. systemd tem agendamento de tarefas e substitui completamente o crond, que por sua vez poderia ter um crash e simplesmente parar de funcionar. E não para por aí o canivete suíço de funcionalidades do systemd.
E nesses anos vimos como Linux chegou ao mundo dos games. Primeiramente de forma modesta com jogos portados pela Loki games. Depois de um tempo de silêncio e de abandono, uma voltou triunfante com o suporte da Steam, a gigante de jogos digitais.
Mas mesmo a Steam passou por maus bocados. Sua estratégia de abraçar o Linux foi para fugir dos braços da Microsoft, que na época mudava sua visão sobre jogos com o Windows 8, tentando forçar os jogadores a usarem sua própria loja de jogos. Então pra ter massa de manobra e poder negociar, a Steam abraçou o Linux. E lançou seu próprio sistema operacional chamado SteamOS, baseado no Debian. E foi um sucesso. Ou quase isso.
A quantidade de jogadores em sistemas Linux chegou a dobrar de 1 para 2%. Mas não mais que isso. Apesar de todo o suporte, o uso nunca cresceu como esperado.
Mas foi o suficiente pra dar o que a Steam precisava: algo pra negociar e tempo. E com o tempo o CEO da Microsoft foi trocado, e por um que tanto declarou amar Linux, e abraçou definitivamente dentro da empresa, assim como provavelmente chegou num acordo com a Steam. E ficamos sem muitas novidades.
Isso até pouco tempo atrás, quando a Steam anunciou novamente algo bastante interessante: Steam deck. Basicamente um PC portátil com tela e controle conectados que permite jogar em qualquer lugar seu catálogo de jogos e... rufem os tambores... rodando Linux. Dessa vez a escolha foi o Arch Linux, a nova distro do pedaço que todo mundo ama. Eu incluso.
Essa nova estratégia da Steam muda seu foco de apenas ser uma plataforma digital de jogos pra vender console de jogos, competindo com Playstation, Xbox e Nintendo Switch. Por outro lado a maioria dos jogos continuaram não sendo nativos pra Linux, mas rodando através de um wine melhorado da própria Steam, o proton. Se chegou agora e não conhece o wine, esse é um software que faz uma tradução das chamadas de programas Windows para Linux. O resultado disso é a possibilidade de rodar programas feitos para Windows diretamente em Linux. E nisso acho que a mudança da Steam vai dar uma piorada pra jogos nativos em Linux. Que estúdio gastará tempo e pessoal pra fazer um jogo que rode em Linux quando pode fazer em Windows, o que provavelmente já fazem, e apenas trabalhar pra rodar bem em proton? Então é uma vitória com um certo gosto amargo de derrota.
Todo os anos eu além de dizer que estou no futuro na virada do ano, também digo que o próximo ano será o ano do Linux no desktop. E isso já faz uns... 15 anos? Talvez mais. Tanto que sempre uso a famosa imagem/meme do nerd dizendo isso (que aliás nem sei quem é pra dar os devidos créditos).
E esse ano nunca chegou. Não da forma que eu imaginava pelo menos. Atualmente o laptop chromebook é um dos mais vendidos para área de educação tanto nos EUA quanto na Europa. O Brasil não entra na conta por ainda viver um bom atraso tecnológico, mas aqui na Suécia minha filha tem seu chromebook na escola pra pesquisar e fazer os exercícios escolares. Na Suécia não houve um lockdown como em outros países durante a pandemia, mas alunos do colegial pra cima foram solicitados pra estudarem de casa. E cada um levou seu chromebook pra isso. E isso aconteceu em vários outros países, não somente aqui.
Sem contar que muitos desktops e laptops foram trocados por tablets e smartphones. Eu mesmo leio bastante em meu tablet Android e passo as manhãs lendo as notícias no meu smartphone (que diga-se de passagem tem a tela tão grande que praticamente precisei comprar uma calça nova e experimentar antes se ele cabia no bolso), também Android. Então a realidade de desktop que esperávamos não é mais aquela de 15 ou 20 anos atrás. Virou uma realidade de cloud, nas nuvens.
Mesmo que, pra desgosto de alguns, cloud rode no computador dos outros, atualmente é impossível fugir dele. Assim como tablets, smartphones, smartTVs, raspberrypis e muitos outros dispositivos, o cloud roda baseado em Linux. Linux virou o senhor supremo de todas as áreas. De geladeiras a super computadores, sendo presença prepobderante na lista dos 500 mais rápidos super computadores do mundo, sendo liderado atualmente pelo Fugaku do Japão com 7.630.848 núcleos de CPU e impressionantes 537.212 teraflops por segundo de desempenho de pico. Nesse é possível jogar minecraft sem lag.
Mas a discussão é no desktop, aquele ambiente dominado pela Microsoft. Sim, esse mesmo. Estamos em 2021 e ainda hoje as pessoas sofrem com vulnerabilidades e malwares enviados por mail no sistema de Redmond. Praticamente o mesmo problema desde que lançaram o Windows 95. E as pessoas continuam usando mesmo assim. Então eu duvido que Linux consiga entrar nesse mercado onde vírus e ransomware já são tidos como coisas absolutamente normais do dia a dia. Ele ficará naqueles que gostam de ter um sistema melhor, mais rápido e mais seguro.
E a liberdade? Sim, existem aqueles que usarão pela liberdade. E talvez por outros motivos. Mas isso não é importante, mesmo que pra eles sejam. O importante é que usem.
E aqui deixo escrito a mensagem que sempre passei e que sempre indignou muita gente: usem software livre. Não percam tempo com política, liberdade, filosofia, etc. Apenas usem se não for seu caso ainda. Isso abrirá portas para você.
Gostou? Então não fique só na instalação de uma distro. Ou de várias. Linux e outros software livres são baseados em... software. Então entre de cabeça. Aprenda a programar usando shell scripts. Depois vá pra linguagens como perl, python e nodejs. E não pare aí. Entre de cabeça.
Ajude um projeto pois tanto Linux quanto todo o ecossistema de software livre ainda dependem de voluntários, que estão ali pra ajudar e aprender. Então participe. Faça parte. Tenho certeza não se arrependerá.
Finalmente deixo aqui meu viva ao Linux e seus 30 anos.
Depois que publiquei o artigo sobre o firewall no openwrt em refatorando meu script de bloqueio de youtube no openwrt, eu ainda precisei dar umas boas mexidas no script pra melhorar. Inclusive comprei até um roteador novo pra poder usar o OpenWRT melhor e com mais facilidade, um Linksys WRT3200ACM que suporta nativamente o OpenWRT. Parece que seu firmware original é até baseado no OpenWRT, mas durou exatamente 5 minutos na minha mão. Só o tempo de conectar e carregar o OpenWRT nele.
O inconveniente é que mexer remotamente em regras de firewall invariavelmente leva a... ficar com a conexão bloqueada. Algumas vezes basta reiniciar mas em outras é preciso rebootar no botão.
Então procurando alguma forma de melhorar meu workflow ao invés de usar o bom e velho XGH, eu acabei achando uma image de VM do openwrt. E instalei aqui usando o libvirt. As imagens ficam aqui:
https://archive.openwrt.org/snapshots/trunk/x86/64/
É um repositório pra x86_64. Eu usei a image openwrt-x86-64-combined-ext4.img.gz, que bastou mapear no virt-manager e usar. Deixei com 2 cpus e 512 MB de RAM, que é a mesma memória disponível no Linksys WRT3200. E isso facilitou bastante mexer com o script. Resolvi um bug que as conexões ficavam ativas quando deveriam estar desabilitadas. Então se for usar meu script, pegue do github pra ter a versão mais atualizada.
No artigo a era do Arch Linux eu esqueci de comentar, mas segue aqui a menção honrosa ao cartão pendrive da FSF que funcionou maravilhosamente pra instalar o Arch. Uma pena que eles não mencionem o suporte ao Arch, assim como não o fazem pro Debian, em usa página de Free distros. O Arch não instala nada pra você. Nem sugere. Mas já faz anos que a FSF adotou uma postura anti-liberdade, onde o bloqueio de uso de firmwares têm de ser forçado goela abaixo do usuário pra ser aprovada. Espero que isso mude em 2022 na FSF.
Já faz um certo tempo que venho acompanhando o Archlinux de perto. Já tinha uma VM rodando pra testes. Mas com a decisão da Steam de lançar o device de games steam deck baseado no Arch, eu realmente fiquei tentado a experimentar mais a fundo, como meu sistema principal no desktop.
Antes de mais nada vou deixar claro que como desktop eu não tenho somente um computador. Tenho um gabinete desktop mesmo, que já descrevi anos atrás no artigo goosfraba, e tenho também o laptop de trabalho. Eu geralmente passo mais tempo no laptop, que roda Ubuntu. O meu desktop estava também com Ubuntu, mas rodando o 21.10. E não tinha reclamações a respeito. Mas faz um tempo que desejo sair do mundo Debian/Ubuntu por vários motivos. De comunidade a questão de forma de participação.
Então aproveitando as férias que peguei nesse fim de ano, resolvi partir pra cima da instalação do Arch. Peço antecipadamente desculpas por ser muita coisa em imagens, mas eu fiz registros dos passos e dificuldades de instalação atráves de imagens em posts no Twitter pra justamente descrever aqui.
Como o computador já roda Ubuntu com LVM, não precisei fazer muita coisa além de criar mais partições que seriam próprias do Arch. Então simplesmente as criei assim:
lvcreate diskspace -L 10G -n archlinux-root
lvcreate diskspace -L 50G -n archlinux-usr
lvcreate diskspace -L 10G -n archlinux-var
E em teoria isso deveria ser o suficiente. Parti pra instalação e o primeiro problema foi encontrar o pendrive pra dar boot na instalação do Arch. Eu tinha criado o pendrive com o comando dd mas eu resolvi seguir à risca a instalação do Arch e refiz o pendrive novamente.
Não que tivesse mudado muita coisa. Eu precisei mexer nos parâmetros de boot da BIOS pra aceitar o pendrive. Depois de algumas configurações extras que mais foram mais próximas ao vodoo, eis que consegui o tão almejado boot.
O boot do Arch foi um passeio no parque. Como ele não faz nada automático e você faz tudo manualmente bastou apenas formatar e montar as partições que eu já tinha criado pra seguir com a instalação.
Nos passos de instalação do grub e meio que empaquei. Eu já tinha o grub instalado na partição UEFI e funcionando no Ubuntu. Seria o caso de apenas adicionar uma nova entrada no grub.cfg? E foi
menuentry 'Arch Linux' --class archlinux --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-16a93a2f-e4a6-4ab3-8eee-b33403509ed4' {
recordfail
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 --hint='hd0,gpt2' bfc3c17e-d451-4c35-8c4a-f93b17436783
else
search --no-floppy --fs-uuid --set=root bfc3c17e-d451-4c35-8c4a-f93b17436783
fi
linux /vmlinuz-linux root=/dev/mapper/diskspace-archlinux--root init=/usr/lib/systemd/systemd ro net.ifnames=0 biosdevname=0 iommu=pt showopts noquiet nosplash verbose
initrd /initramfs-linux.img
}Com isso eu consegui deixar a opção de boot do Arch disponível. Existe aí um pequeno problema, o tal elefante na sala: o que acontece quando o Ubuntu atualizar. Eventualmente eu devo dar boot no Ubuntu e rodar algum upgrade de kernel. Ao rodar o mkinitram, com certeza vai sobreescrever essa entrada. Ainda não resolvi esse problema, mas por enquanto sigo usando somente Arch.
Então a coisa foi mesmo fácil e bastou apenas apertar o <Enter>...
O que deu errado? E aqui eu comecei a entender um pouco mais do Arch além da superfície. E essa era meu objetivo desde o início. Pra entender o problema é preciso olhar como são os diretórios dentro do Arch primeiro.
root@goosfraba /u/bin# ls -l /
total 28
lrwxrwxrwx 1 root root 7 Dec 7 03:41 bin -> usr/bin
drwxr-xr-x 5 root root 4096 Dec 27 21:51 boot
drwxr-xr-x 23 root root 4600 Dec 29 00:12 dev
drwxr-xr-x 3 root root 4096 Jan 1 1970 efi
drwxr-xr-x 90 root root 8192 Dec 29 13:48 etc
drwxr-xr-x 35 root root 4096 Jun 9 2020 home
lrwxrwxrwx 1 root root 7 Dec 7 03:41 lib -> usr/lib
lrwxrwxrwx 1 root root 7 Dec 7 03:41 lib64 -> usr/lib
drwxr-xr-x 2 root root 6 Dec 7 03:41 mnt
drwxr-xr-x 11 root root 154 Dec 29 13:48 opt
dr-xr-xr-x 437 root root 0 Dec 27 21:59 proc
drwxr-x--- 14 root root 239 Dec 29 13:27 root
drwxr-xr-x 26 root root 740 Dec 29 00:45 run
lrwxrwxrwx 1 root root 7 Dec 7 03:41 sbin -> usr/bin
drwxr-xr-x 4 root root 29 Dec 27 21:17 srv
dr-xr-xr-x 13 root root 0 Dec 27 21:59 sys
drwxrwxrwt 24 root root 4096 Dec 29 13:48 tmp
drwxr-xr-x 23 root root 332 Jun 19 2018 ubuntu
drwxr-xr-x 9 root root 118 Dec 29 13:48 usr
drwxr-xr-x 14 root root 201 Dec 29 12:58 var
O Arch não tem /bin, /sbin, /lib e /lib64. Ele joga todos os executáveis em /usr/bin e todas as libs em /usr/lib. Isso talvez facilite algum tipo de manutenção, mas quebra o princípio de que pra dar boot todo o necessário deveria estar em /bin pra executáveis de usuário e /sbin pra executáveis de root. Assim como a libc em /lib. O problema foi que eu tinha criado uma partição /dev/devicemapper/diskspace-arch--usr e montado no /usr, que não é passada no boot, que pede somente a partição root.
Então tive de replanejar minha instalação aumentando a partição raiz e removendo a partição que abrigava o /usr.
E finalmente copiar os dados do que era /usr.
E finalmente remover a partição criada pra abrigar originalmente o /usr.
Com isso eu pude finalmente dar boot no Arch e subir o KDE plasma.
Mas foi só isso. Não consegui mexer em mais nada. O que deu errado? Primeiramente foi a escolha de KDE que fiz durante a etapa do pacstrap. Eu escolhi o plasma-desktop e o mesmo não vem completo, o certo era plasma-meta. Não tinha um shell pra eu abrir como o gnome-terminal nem konsole. E como habilitei o sddm, então não conseguia voltar pro console virtual usando <ctrl>+<alt>+<F1>. Fiquei empacado. E precisei novamente dar boot pelo pendrive pra corrigir isso.
E consegui subir meu ambiente da mesma forma que antes. Apenas re-criei meu usuário com mesmo UID e GID e montei a mesma partição /home que era do Ubuntu. Transparentemente.
É nítida a diferença do primeiro screenshot do neofetch pro segundo, em como as fontes melhoraram. Aos poucos vou instalando e habilitando aquilo que preciso no Arch.
Eu de cara já sai com alguns extras funcionando sem mexer, como o Google Chrome, que aparece na imagem do desktop. Como estava na partição /opt, eu simplesmente montei e re-usei. Instalei o programa yay pra baixar pacotes faltando como steam e spotify. Ambos já instalados. E aos poucos vou arrumando a casa.
Um dos problemas que encontrei foi que minha partição de jogos da steam não aparecia disponível. Mas estava lá no comando lvs:
root@goosfraba /u/bin# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
archlinux-root diskspace -wi-ao---- 60.00g
archlinux-var diskspace -wi-ao---- 10.00g
debian diskspace -wi-a----- 10.00g
docker diskspace -wi-ao---- 30.00g
home diskspace -wi-ao---- 500.00g
linux-arch diskspace -wi-a----- 20.00g
opt diskspace -wi-ao---- 4.00g
root diskspace -wi-ao---- 10.00g
steam diskspace rwi-aor--- 750.00g 100.00
swap diskspace -wi-a----- 15.00g
tmp diskspace -wi-ao---- 5.00g
usr diskspace -wi-ao---- 95.00g
usrlocal diskspace -wi-ao---- 600.00g
var diskspace -wi-a----- 50.00g
O problema era que precisava ativar a partição, que faz mirroring entre os dois HDs que tenho. Bastou fazer o comando:
lvchange -a y /dev/diskspace/steamE meu steam passou a funcionar de novo.
E como eu já deixei o docker em um partição só sua, bastou montar pra ter novamente os containers que uso disponíveis no Arch.
root@goosfraba /u/bin# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
debian 11.0 6c97952ad9c0 6 days ago 626MB
theiaide/theia-full latest de7823cee314 2 months ago 11.5GB
debian <none> a178460bae57 3 months ago 124MB
theiaide/theia-full <none> 9c178198e255 3 months ago 8.86GB
No arch já sai com o python 3.10 funcionando.
E pra minha surpresa a instalação do suporte à NVIDIA foi fácil e tranquilo. Mais que no Ubuntu.
Como foi possível ver é bem divertido o uso do Arch e resgata um pouco daquele espírito hacker de fuçar no seu sistema operacional pra ter tudo funcionando. Eu estou gostando da experiência por equanto. Acho que agora já posso fazer como o Kretcheu, se bem que Debian eu já não uso faz alguns anos.
