 |
| Redcore Linux instalado e atualizado |
Redcore se propõe "levar o poder do Gentoo para as massas" — por isso, foi a distro que escolhi para substituir o saudoso Sabayon como "distro de entrada" para esse ramo do Linux.
A instalação do Redcore Linux Hardened 2102 (=2021 nº 2, lançado em Outubro 2021) transcorreu sem qualquer problema — e a atualização inicial se completou na segunda tentativa, com as demoras que, afinal, eram previstas e avisadas.
As demais atualizações se completaram sem problemas — exceto alguns casos específicos, relatados mais à frente.
Por enquanto, uso o comando sisyphus para atualizar o sistema, e para procurar e instalar novos pacotes — nunca o Discover. — Evito usar o emerge (Portage), enquanto aprendo (para não me confundir); e comecei a explorar as flags USE.
A instalação de pacotes adicionais também não foi difícil, mesmo sem conhecimento anterior do Redcore ou do Gentoo. — Ainda não consegui instalar algumas coisas bem comuns, como o GoogleEarth; enquanto o Dolphin continua sem algumas características encontradas em todas as outras distros que já instalei, como exibir os dados Exif das fotos — mas tenho trabalhado com o Redcore Linux sem grandes dificuldades, nos últimos 40 dias.
Isto NÃO é um tutorial — mas, apenas, um registro da minha experiência (com possíveis erros, que ainda não percebi). — Estruturar um relato, como este, me obriga a revisar cada detalhe, solucionar problemas, deixar a distro bem afinada, aprender coisas novas — e fico feliz se for útil aos colegas que se aventuram no mundo Linux sem serem "especialistas".
Meu hardware atual é bastante razoável para compilar meia-dúzia de pacotes em algumas atualizações (que faço aos domingos) — mas acabei desativando o Intel Turbo Boost (eu não jogo), por motivos que explico adiante:
Mobo: TUF B360M-PLUS GAMING/BR, BIOS 2401 03/22/2019 - ASUSTeK
iGPU: Intel Corporation UHD Graphics 630 (Desktop)
Processors: 6 × Intel® Core™ i5-9400 CPU @ 2.90GHz (min / max: 800 ~ 4100 MHz)
Memory: 15.5 GiB of RAM
Índice
- Download
- Particionamento
- Instalação
- Atualização inicial
- Sisyphus
- Configurações
- CPU e Temperatura
- Dolphin
- Flags USE
- Redcore 2201
- “There is NOT at least 6400 MiB disk space at...”
- Por que Redcore Linux?
Download
 |
| Download da ISO do Redcore Linux 2102 pelo navegador |
12 Junho 2022 - Clicar nos links da página de downloads do Redcore Linux não produz nenhum resultado, no meu navegador. — No ano passado, cliquei em cada item com o botão direito do Mouse para "copiar o link", e em seguida colei no Terminal, para fazer o download com o wget.
Este ano, cliquei com o botão direito do Mouse e escolhi "salvar o link como". — O navegador iniciou os downloads, mas parou no final. — No rodapé do navegador, um aviso de que "não pode ser baixado com segurança".
Cliquei na seta ao lado dos botões "descartar", fui à página de downloads do navegador — cliquei em "manter" (tive de confirmar) — e finalmente os arquivos foram salvos no HDD.
No ano passado, a velocidade de download passou um pouco de 20 MiB/s (segundo o Conky) e a média ficou em 16,9 MB/s (segundo o wget); — e este ano, chegou a 21,7 MiB/s (segundo o Conky) — o que está bem perto do limite de 26,1 MiB/s da minha conexão de "200 megas".
Isso me animou bastante, pois prenunciava boas velocidades de download também nas atualizações. — A imagem ISO veio da Universidade de Princeton, nos EUA — país ao qual a internet do Brasil está umbilicalmente conectada.
Depois de instalado, verifiquei que o Sisyphus já veio configurado para usar o espelho de Princeton — o que é bom, pois a conexão do Brasil com a Europa é indireta (passando pelos EUA) — e com a Rússia nunca foi boa (hoje, talvez, pior):
# sisyphus mirror list
1 http://mirrors.redcorelinux.org/redcorelinux/amd64/packages/
2 http://mirrors.redcorelinux.org/redcorelinux/amd64/packages-next/
3 * http://mirror.math.princeton.edu/pub/redcorelinux/amd64/packages/
4 http://mirror.math.princeton.edu/pub/redcorelinux/amd64/packages-next/
5 http://mirror.alpix.eu/redcorelinux/amd64/packages/
6 http://mirror.alpix.eu/redcorelinux/amd64/packages-next/
7 http://mirror.yandex.ru/mirrors/redcorelinux/amd64/packages/
8 http://mirror.yandex.ru/mirrors/redcorelinux/amd64/packages-next/
Por enquanto, evito os repositórios "packages-next" (testing).
 |
| Verificação sha256sum com ajuda do KWrite |
Fiz a verificação da imagem ISO do Redcore Linux pelos comandos sha256sum e md5sum e colei os resultados no campo de busca do KWrite, para não errar nem perder tempo.
 |
| "Queima" do DVD pelo K3b, na menor velocidade disponível |
"Queimei" o DVD pelo K3b, na menor velocidade permitida pelo hardware — um hábito que adotei há alguns anos, para reduzir perdas de mídia.
Particionamento
 |
| Criando partições e "movendo" para elas o Mocaccino |
Não gosto de usar instaladores para particionar discos, pois nem sempre fazem o que penso ter entendido de suas interfaces. — Prefiro fazer o particionamento antes, usando o GParted ou o KDE Partition Manager, dos quais já sei exatamente o quê esperar.
O primeiro passo foi criar 2 novas partições e "colar" nelas (copy & paste) as partições Linux11 e Home11 — onde estava o Mocaccino OS. — Em seguida, alterei os Rótulos das cópias para Linux11b e Home11b, para evitar confusão, pois uso esses Rótulos na montagem automática (udisks2), no Conky, e até no /etc/fstab do Debian.
 |
| Formatando e tornando a rotular Linux11 e Home11 |
Por fim, formatei as partições Linux11 e Home11 originais — para mudar seus identificadores UUID — e tornei a aplicar esses rótulos.
Instalação
 |
| Início da sessão Live do Redcore Linux |
Infelizmente, não encontrei nenhum aplicativo de captura de tela na sessão Live — por isso, tive de me conformar com fotos (bem ruins) pelo celular.
O instalador (Calamares) é muito prático. — Para começar, troquei o Idioma inglês "americano" pelo inglês do Reino Unido; selecionei o Fuso horário BRT; e Teclado Brasil (padrão = ABNT2).
Na etapa "Partições", selecionei "Particionamento manual" — para ter completa liberdade de escolher as partições que iria usar, e que já estavam prontas. — Talvez a opção "Substituir uma partição" servisse para fazer isso, mas preferi não arriscar.
Selecionei e "editei" as partições Linux11 para "raiz" (/), Home11 para a pasta pessoal (/home) — sempre verificando que não estivessem marcadas para formatar.
Antes de prosseguir, o instalador reclamou que faltava escolher a partição EFI. — Selecionei, editei, e me certifiquei de que não estava marcada para formatar.
Tentei selecionar também a partição Swap, mas não vi como fazer isso. — É fácil habilitar Swap mais tarde.
Na etapa "Usuários", dei ao computador o nome "Redcore" (era para ser Linux11, mas foi bom para identificar melhor no celular) — selecionei Login Automático — e criei uma senha separada para o Administrador (Root).
 |
| Resumo das escolhas, antes de realizar a instalação efetiva |
Antes de efetivar a instalação no computador, o instalador apresenta um resumo das escolhas feitas pelo usuário — e esta é a última oportunidade para corrigir alguma coisa.
Obs.: - O Live Redcore Linux inverteu as posições de sda e sdb — e foram os Rótulos das partições (Linux11, Home11, EFI), visíveis na etapa "Partições", que me ajudaram a evitar algum desastre.
Depois de instalado, às vezes ainda inverte sda e sdb — e outras vezes inverte sdb e sdc.
A instalação efetiva foi menos demorada do que eu esperava — cerca de 20 minutos (de DVD para SSD), contados pela hora das fotos — e para variar, os percentuais da barra de progresso do Calamares guardam pouca relação com a realidade.
Atualização inicial
 |
| Início da primeira atualização |
A primeira atualização do Redcore Linux previa atualizar 984 pacotes binários — mas abortou após baixar 633, em 1 hora 19 minutos:
# date; sisyphus upgrade; date
Sun 12 Jun 16:54:24 -03 2022
These are the binary packages that would be merged, in order:
(...)
Total: 984 binary package(s)
Would you like to proceed? [y/N] y
(...)
>>> Downloading binary (632 of 984) gui-libs/libwpe-1.12.0.tbz2
100% [..............................................................] 83034 / 83034
>>> Downloading binary (633 of 984) media-libs/libplacebo-4.192.1.tbz2
Traceback (most recent call last):
File "/usr/lib/python3.9/urllib/request.py", line 1786, in open
return getattr(self, name)(url)
(...)
File "/usr/lib/python3.9/socket.py", line 832, in create_connection
sock.connect(sa)
OSError: [Errno socket error] [Errno 110] Connection timed out
Sun 12 Jun 18:13:12 -03 2022
Tornei a executar o comando de atualização — e ele anunciou que iria baixar 984 pacotes binários — sem nenhum desconto pelos 633 baixados minutos antes.
Dessa vez, a atualização se concluiu sem qualquer falha, após 3 horas 51 minutos, e no final deixou 420 linhas de mensagens para ler.
 |
| Velocidades de download durante o upgrade do Redcore Linux |
A demora não se deve à velocidade de download, que atinge bons níveis — mas às interrupções ao final de cada pacote (picos isolados) — com grandes intervalos entre um pacote e outro.
Isso lembra um pouco o comportamento das atualizações no Sabayon — que costumava baixar 3 pacotes de cada vez, interrompendo o download por algum tempo, depois baixava mais 3 pacotes, e assim por diante.
 |
| Poucos momentos de intensa atividade de processamento |
Houve poucos momentos de intensa atividade de processamento. — Como ainda não entendo do assunto, só posso imaginar que houve alguma compilação, aqui e ali. — E mesmo depois de terminado o download geral, alguma coisa ainda precisou ser baixada pelo emerge (acho), durante o processamento.
Como resultado dessa atualização, que cobre 8 meses, desde o lançamento da ISO (Outubro 2021), o KInfocentre indica as diferenças de Kernel e Plasma:
2022-06-12 16:48:41 | 2022-06-13 00:17:38
|
Operating System: Redcore Linux Hardened | Operating System: Redcore Linux Hardened
KDE Plasma Version: 5.22.5 | KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.86.0 | KDE Frameworks Version: 5.93.0
Qt Version: 5.15.2 | Qt Version: 5.15.3
Kernel Version: 5.14.10-redcore (64-bit) | Kernel Version: 5.14.21-redcore (64-bit)
Sisyphus
 |
| Enfim, captura de tela no Redcore Linux |
É claro que aproveitei esse tempo — do final da instalação, às 16:29, até o final da atualização, às 22:12 — para fazer pequenas configurações, principalmente no KDE Plasma.
Mas só depois da atualização poderia instalar algumas ferramentas mais urgentes — e aí já me deparei com a eventual necessidade da opção --ebuild do Sisyphus:
# history | grep install
...
11 date; sisyphus install conky; date
16 date; sisyphus install gnome-screenshot --ebuild; date
19 date; sisyphus install kdeconnect; date
24 2022-06-12_22-42-36 date; sisyphus install inxi ; date
26 2022-06-12_22-44-38 date; sisyphus install screenfetch; date
28 2022-06-12_22-46-03 date; sisyphus install neofetch; date
50 2022-06-12_23-50-37 date; sisyphus install kate; date
56 2022-06-13_00-59-44 date; sisyphus install krename --ebuild; date
58 2022-06-13_01-15-59 date; sisyphus install google-chrome; date
94 2022-06-14_08-54-17 date; sisyphus install dmidecode --ebuild; date
116 2022-06-14_23-16-39 date; sisyphus install kruler --ebuild; date
124 2022-06-15_21-25-54 date; sisyphus install corefonts; date
132 2022-06-16_11-21-23 date; sisyphus install kdesdk-thumbnailers --ebuild; date
137 2022-06-16_11-31-21 date; sisyphus install baloo-widgets --ebuild; date
142 2022-06-16_11-42-42 date; sisyphus install kdegraphics-mobipocket --ebuild; date
152 2022-06-16_12-18-02 date; sisyphus install krusader --ebuild; date
190 2022-06-16_15-51-22 date; sisyphus install konqueror --ebuild; date
237 2022-06-17_10-48-12 date; sisyphus install app-text/html2text --ebuild; date
267 2022-06-18_10-28-21 date; sisyphus install filelight --ebuild; date
269 2022-06-18_10-29-58 date; sisyphus install kdiff3 --ebuild; date
289 2022-06-19_17-20-43 date; sisyphus install youtube-dl --ebuild; date
298 2022-06-20_11-36-05 date; sisyphus install imagemagick --ebuild; date
305 2022-06-20_16-23-59 date; sisyphus install foliate --ebuild; date
307 2022-06-20_16-34-50 date; sisyphus install kstars --ebuild; date
...
300 2022-06-20_22-19-45 date; sisyphus install foliate --ebuild; date
311 2022-06-22_10-01-06 date; sisyphus install app-misc/screen --ebuild; date
315 2022-06-22_10-24-57 date; sisyphus install www-client/links --ebuild; date
336 2022-06-30_13-23-53 date; sisyphus install scrcpy --ebuild; date
382 2022-07-17_15-33-24 date; sisyphus install media-libs/libexif; date
389 2022-07-18_12-18-18 date; sisyphus install kde-apps/marble; date
393 2022-07-19_14-10-00 date; sisyphus install app-misc/mc --ebuild
477 2022-07-21_01-45-01 date; sisyphus install net-analyzer/speedtest-cli --ebuild; date
Por padrão, o Sisyphus só lida com pacotes binários — mas quando não encontra, ele poderá avisá-lo, caso existam ebuilds — arquivos do repositório Gentoo com a informação que o Portage necessita para manter o software (instalar, procurar).
Então, você repete o comando, acrescentando essa opção — mas, para não perder tempo, é melhor usá-la sempre. — A opção --ebuild (ou apenas -e) pode ser usada o tempo todo, pois ela dá preferência aos pacotes binários, se nenhuma compilação for necessária.
Com um comando sisyphus search dolphin, por exemplo, eu encontrei apenas 3 pacotes — mas com a opção --ebuild encontrei 8 pacotes.
Vale notar que o sisyphus install só aceita o nome simples do pacote, se ele for “único“. — Caso contrário, dirá que não encontrou. — Neste caso, é preciso especificar “Categoria/Pacote”.
 |
| Midnight Commander no Sisyphus GUI |
Mesmo na busca, deixar de indicar a Categoria pode dificultar as coisas. — Levei 3 dias para encontrar o Midnight Commander (mc) — brigando com o reduzido sisyphus --help (pois não existe man sisyphus).
Por fim, me deparei na web com o “nome completo”— app-misc/mc — e só mais tarde descobri que, pelo Sisyphus GUI, (acima) eu não teria gastado nem 1 minuto:
# history | grep 'mc\|midnight\|commander'
61 2022-06-13_10-27-38 sisyphus install mc
62 2022-06-13_10-28-38 sisyphus install midnight-commander
149 2022-06-16_12-15-14 sisyphus search commander --ebuild
157 2022-06-16_14-25-24 sisyphus search commander -d -e
158 2022-06-16_14-26-56 sisyphus search commander -d 'file manager' -e
159 2022-06-16_14-28-01 sisyphus search commander -d 'Midnight Commander'' -e
160 2022-06-16_14-28-21 sisyphus search commander -d 'Midnight Commander' -e
191 2022-06-16_19-03-36 sisyphus search mc --ebuild
192 2022-06-16_19-06-04 sisyphus search mc -d 'commander' --ebuild
193 2022-06-16_19-06-30 sisyphus search mc -d 'midnight commander' --ebuild
194 2022-06-16_19-06-52 sisyphus search "" -d 'midnight commander' --ebuild
196 2022-06-16_19-09-08 sisyphus search app-misc* -d 'midnight commander' --ebuild
200 2022-06-16_19-11-08 sisyphus search root/app-misc/mc/mc-4.8.28-r1.ebuild --ebuild
201 2022-06-16_19-11-27 sisyphus search mc-4.8.28-r1.ebuild --ebuild
410 2022-07-19_14-08-23 sisyphus search app-misc/mc --ebuild
411 2022-07-19_14-10-00 sisyphus install app-misc/mc --ebuild
Olhando agora o histórico dos comandos, é fácil ver quantos erros de “lógica” eu cometi — mas na hora, a situação parecia desanimadora.
Enfim, até uma simples busca implica em nova consulta aos repositórios. — O Sisyphus não dá 1 passo sem verificar tudo de novo. — Se você fizer 10 buscas, uma após outra, terá 10 demoras iniciais.
Para desocupar espaço em disco, após 4 dias (16 Jun) usei o comando # sisyphus autoremove — que remove pacotes órfãos. — Isso reduziu em 2,4 GiB o uso da partição-raiz (de 16,9 para 14,5 GiB).
Para contar os pacotes instalados, usei o comando # qlist -I | wc -l — que apontou o mesmo número indicado pelo Neofetch (1.454, naquele momento). — Para guardar uma lista de todos os arquivos instalados, usei o comando # qlist -I > qlist--installed.txt (pena que não era mais a instalação original, para documentar).
Outros 2 comandos permitiram registrar mais detalhes dos pacotes instalados:
# sisyphus search "" -f installed >> installed.txt
# sisyphus search "" -f alien >> installed-alien.txt
Este último comando encontrou 8 pacotes "alien": — podofo, baloo, baloo-widgets, krename, krusader, gnome-screenshot, além do vimcommander (que instalei à toa) e uma biblioteca libhandy.
Falta ler mais algumas coisas sobre liberar espaço em disco — em especial eclean.
Configurações
 |
| Nome e versão do init do Redcore Linux, no Conky (imagem posterior) |
Para a linha do Conky que exibe o software init e sua versão:
${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 rc-service -V | cut -c 21-26}
... utilizei um vetusto comando strings (ainda do tempo do upstart) — e em seguida, o recém-aprendido comando rc-service (Gentoo, Alpine Linux) — cujo resultado colei no Kate / KWrite, para “contar“ a posição a ser usada no comando cut:
# echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')
openrc
$ rc-service -V
rc-service (OpenRC) 0.42.1 (Redcore Linux Hardened)
1 2 3 4 5
123456789012345678901234567890123456789012345678901234567890
$ rc-service -V | cut -c 12-26
(OpenRC) 0.42.1
$ rc-service -V | cut -c 21-26
0.42.1
Dividi a linha em 3 pedaços (\) nas configurações do Conky, para facilitar minha vida:
1) Os primeiros 2 trechos (sysname, kernel, strings) são válidos em todas as 12 distros que mantenho instaladas — o que facilita manter um "modelo" de arquivo de configuração facilmente aplicável a qualquer distro, mesmo em sessão Live.
2) O comando strings me dá a certeza de qual init está de fato em uso — pois em algumas distros pode haver mais de 1 instalado. — Assim, evito indicar o init errado, caso escolhesse (por engano) apenas um comando específico... de outro:
[PATH]/Warehouse/Byteria/Conky/backup/2022-07-18
$ grep -R -A 2 sysname
openSUSE ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Arch ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Debian ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Fedora ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
KDE Neon ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
PCLinuxOS Kernel ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}
Mageia ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Slackware ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}
Void ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')}
Manjaro ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Redcore ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 rc-service -V | cut -c 21-26}
MX Linux ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}
3) Apenas o terceiro trecho é específico de cada distro — comandos escolhidos à mão, caso por caso (com base na resposta ao comando strings), para obter a versão do respectivo init — o que ainda não descobri como fazer no Void Linux.
 |
| Memória, Processos e Pacotes do Redcore Linux, no Conky (imagem posterior) |
No bloco do Conky que exibe várias medidas desencontradas do uso de Memória RAM (Conky2, à direita), desabilitei a linha do htop — pois ainda não encontrei o pacote aha (Ansi HTML Adapter), necessário para converter a saída em formato web. — Até agora, só encontrei o html2text, que completaria a conversão para texto puro (plain text).
Mem: ${alignr 100}up ${uptime}
Total - Available ${alignr 100}${exec bash MemInfo.sh; cat MemInfo.txt}
Conky (Mem) ${alignr 100}${mem}
free ${alignr 100}${exec free -m | grep Mem | cut -c 25-35} MiB
top ${alignr 100}${exec top -E m -b -n 1 | grep buff | cut -c 41-50} MiB
neofetch ${alignr 100}${exec neofetch --stdout | grep "Memory" | grep -o -P '.{0,0}Memory.{0,9}' | cut -b 8-12} MiB
# htop ${alignr 100}${exec echo q | htop | aha --line-fix | html2text | grep -o -P '.{0,6}/15' | cut -b 1-6}iB
inxi ${alignr 100}${exec inxi --memory-short | grep -o -P '.{0,0}used.{0,14}' | cut -b 6-14}
screenfetch ${alignr 100}${exec screenfetch -n -N | grep -o -P '.{0,0}RAM.{0,9}' | cut -b 5-12}
${execi 600 neofetch --de_version on --stdout | grep "Packages:"}
${execi 600 neofetch --de_version on --stdout | grep "DE:"}
${execi 600 kf5-config --version | grep 'Qt\|KDE'}
${execi 600 konsole -v} ${alignr 60}${execi 600 kate -v}
${execi 600 dolphin -v} ${alignr 60}${execi 600 gwenview -v}
${execi 600 neofetch --de_version on --stdout | grep "CPU\|GPU"}
$hr
 |
| Datação do histórico dos comandos no arquivo .bashrc (imagem posterior) |
Por volta de 22:40, lembrei de datar os comandos no .bash_history — tanto do usuário quanto do Administrador. — A data e a hora dos comandos só passa a ser registrada após fechar e reiniciar o Konsole (como fiz); ou de imediato, recarregando suas configurações pelo comando source:
$ echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
$ source ~/.bashrc
# echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
# source ~/.bashrc
$ history
2 2022-06-12_22-40-26 su
3 2022-06-12_22-40-26 su
4 2022-06-12_22-40-26 sensors
6 2022-06-12_22-40-26 su
7 2022-06-12_22-40-26 echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
8 2022-06-12_22-40-32 history
# history
1 2022-06-12_22-40-55 sisyphus mirror list
2 2022-06-12_22-40-55 date; sisyphus spmsync; date
3 2022-06-12_22-40-55 date; sisyphus update; date
4 2022-06-12_22-40-55 date; sisyphus upgrade; date
5 2022-06-12_22-40-55 date; sisyphus upgrade; date
7 2022-06-12_22-40-55 date; sisyphus upgrade; date
11 2022-06-12_22-40-55 date; sisyphus install conky; date
16 2022-06-12_22-40-55 date; sisyphus install gnome-screenshot --ebuild; date
18 2022-06-12_22-40-55 date; sisyphus search kdeconnect; date
19 2022-06-12_22-40-55 date; sisyphus install kdeconnect; date
21 2022-06-12_22-40-55 echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
22 2022-06-12_22-41-00 history
Os comandos executados antes desse momento permanecem não-datados — e aparecem com a data e hora do momento em que se executa o comando history. — Por isso, eu não saberia quando instalei o Conky, o gnome-screenshot e o KDE Connect (sem recorrer aos logs do sistema), se não incluísse date no início e no final dos comandos sisyphus.
Para procurar nos logs, o genlop aceita parâmetros que permitem selecionar, por exemplo, após a atualização inicial e o dia seguinte:
# genlop --list --date Sun 12 Jun 22:20:00 2022 --date Mon Jun 13 22:00:00 2022
Sun Jun 12 22:25:19 2022 >>> net-wireless/wireless-tools-30_pre9-r1
Sun Jun 12 22:25:23 2022 >>> dev-lang/lua-5.3.6-r3
Sun Jun 12 22:25:27 2022 >>> app-admin/hddtemp-0.3_beta15-r29
Sun Jun 12 22:25:32 2022 >>> net-libs/libircclient-1.10
Sun Jun 12 22:25:37 2022 >>> app-admin/conky-1.12.2
Sun Jun 12 22:30:20 2022 >>> gui-libs/libhandy-1.6.2
Sun Jun 12 22:30:30 2022 >>> media-gfx/gnome-screenshot-41.0
Sun Jun 12 22:34:16 2022 >>> x11-libs/libfakekey-0.3-r1
Sun Jun 12 22:34:20 2022 >>> dev-libs/kpeoplevcard-0.1-r1
Sun Jun 12 22:34:24 2022 >>> media-libs/pulseaudio-qt-1.3-r1
Sun Jun 12 22:34:28 2022 >>> net-fs/sshfs-3.7.1
Sun Jun 12 22:34:33 2022 >>> kde-misc/kdeconnect-22.04.0
Sun Jun 12 22:43:11 2022 >>> sys-apps/inxi-3.3.13.1
Sun Jun 12 22:45:11 2022 >>> app-misc/screenfetch-3.9.1-r1
Sun Jun 12 22:46:28 2022 >>> app-misc/neofetch-7.1.0-r1
Sun Jun 12 23:51:06 2022 >>> kde-apps/kate-22.04.0
Mon Jun 13 01:00:47 2022 >>> app-text/podofo-0.9.7
Mon Jun 13 01:01:09 2022 >>> kde-misc/krename-5.0.1-r1
Mon Jun 13 01:17:17 2022 >>> www-client/google-chrome-101.0.4951.64
22:54 - Várias coisas dependiam da montagem automática de partições adicionais — que eu estava evitando, para não criar pontos de montagem pertencentes ao Administrador. — Para isso, eu precisava criar um arquivo /etc/polkit-1/rules.d/99-udisks2.rules e colar nele uma autorização para a montagem dessas partições pelo udisks2 sem privilégios:
# history
37 2022-06-12_22-54-52 nano /etc/polkit-1/rules.d/99-udisks2.rules
Pasted content:
# cat /etc/polkit-1/rules.d/99-udisks2.rules
// Allow udisks2 to mount devices without authentication
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.udisks2.filesystem-mount-system" || action.id == "org.freedesktop.udisks2.filesystem-mount" || action.id == "org.freedesktop.udisks2.filesystem-mount-system-internal") { return polkit.Result.YES; } });
 |
| Criando atalhos para o gnome-screenshot no Redcore Linux KDE |
Ainda precisei instalar inxi, Screenfetch, Neofetch — e configurar os atalhos para o gnome-screenshot:
PrtScn --- capturar e salvar
gnome-screenshot -p -f PATH/$(date +%F_%H-%M-%S)_Rc.jpg
Shift+PrtScn --- com espera de 7 segundos
gnome-screenshot -p -d 7 -f PATH/$(date +%F_%H-%M-%S)_Rc.jpg
CTRL+Shift-PrtScn --- capturar janela ativa
gnome-screenshot -w -p -f PATH/$(date +%F_%H-%M-%S)_Rc.jpg
 |
| Instalando fontes a partir de arquivos locais |
Executei o sensors-detect, para configurar o sensors, necessário para o Conky exibir as Temperaturas de modo correto. — Instalei algumas fontes a partir de velhos arquivos locais e executei o comando # fc-cache -fv para atualizar o cache de fontes.
 |
| Habilitando Compositor para obter Transparência no Redcore KDE |
Por algum motivo, o Compositor de Tela ainda precisava ser habilitado para as sessões do Plasma KDE, para obter Transparência no Conky, no Painel, no Menu (tema Maia Transparent, originário do Manjaro) e na decoração das janelas (Transparent Oxygen).
Isso também aconteceu no Debian testing, há alguns meses.
 |
| Copiando scripts de outra partição /home |
Copiei da /home de outra distro (Home10) o script MemInfo.sh, que calcula o uso de Memória RAM conforme proposto por Linus Torvalds em 2014 — para vigiar os cálculos do Conky e das demais ferramentas:
MEM_TOTAL=$(awk '/MemTotal/ { printf $2 }' /proc/meminfo); \
MEM_AVAIL=$(awk '/MemAvailable/ { printf $2 }' /proc/meminfo); \
MEM_USED_KILO="$(($MEM_TOTAL-$MEM_AVAIL))"; \
echo "$(($MEM_USED_KILO/1024))" MiB > MemInfo.txt
(*) Me parece incorreto dividir (MemTotal - MemAvailable) / 1024, pois o “kB” (com k minúsculo) no /proc/meminfo é muito claro em se referir ao sistema SI (portanto, o divisor deveria ser 1024² / 1000 = 1048,576) — mas essa parece ser a prática adotada pelos desenvolvedores das várias ferramentas — e a diferença de +2,4% é irrelevante, dadas as oscilações normais de uso de RAM a cada segundo.
 |
| Montagem pelo UDisks2 e cópia de Autostarts do Conky |
Enfim, montei manualmente as partições adicionais pelo Dolphin (udisks2) e ocultei as que uso pouco. — Com a perspectiva de montagem automática (a seguir), aproveitei para copiar de outra distro os arquivos de início automático do Conky.
 |
| Uma segunda instância do Conky exige outro arquivo de configuração |
13 Jun 2022 - Uma segunda instância do Conky, precisa de outro arquivo de configuração:
conky -c /home/flavio/.config/conky/conky2.conf
(comando do início automático do Conky 2).
 |
| Montagem automática de todas as partições |
Pelo KDE System Settings >> Removable storagem >> Removable devices, podem-se marcar uma ou várias partições adicionais para montagem automática no início da sessão Plasma pelo UDisks2 (sem incluí-las no fstab) — ou marcar todas com apenas 1 clique, no alto.
Dependendo da distro, basta fazer isso 1 vez — ou um punhado de vezes. — Depois, a montagem automática se normaliza e só em raros casos volta a falhar.
No Redcore Linux, a montagem automática só passou a funcionar por completo depois de vários Restart — e para isso, torno a montar manualmente as que faltam, pelo Dolphin, até adestrar o UDisks2. — Mas voltou a falhar algumas vezes, ao longo da semana.
 |
| Inversão de sdb e sdc no Redcore Linux |
Primeiro, atribuí essas falhas ao fato de que, às vezes, o Redcore inverte as posições de sda e sdb — e outras vezes inverte sdb e sdc — embora os dispositivos estejam sempre plugados nos slots Sata nº 1, Sata nº 2, Sata nº 3.
 |
| Manter a lista dos "Dispositivos desconectados" |
Esse talvez fosse um dos motivos pelo quais o KDE System Settings desenvolve uma longa lista de "dispositivos desconectados" — com as mesmas partições montadas no momernto (logo acima). — Com o tempo, todas as possíveis alternativas acabaram sendo "cadastradas" e lembradas, e a montagem automática passou a funcionar em todas as inicializações do sistema.
Nesse afã de normalizar a montagem automática das partições adicionais, resolvi deletar logo as partições do Mocaccino OS — sem lembrar das anotações e capturas de tela que ainda estavam em sua /home.
Entre um Restart e outro, comecei a configurar o Kate e o KWrite — e prossegui nas semanas seguintes.
 |
| Dando ao Usuário a posse dos pontos de montagem do Redcore |
Outro dos possíveis motivos, é que vários pontos de montagem pertenciam ao Administrador (Root) — um problema que eu já tinha enfrentado em outras distros, após um upgrade do KDE — e que atrapalha a montagem automática pelo UDisks2.
Na minha ingenuidade, eu também achava que uma das "vantagens" de usar pontos de montagem em /media/$USER/ ou em /run/media/$USER/ fosse sua "limpeza" completa, ao encerrar a sessão do Usuário — quando essa pasta é esvaziada (ou deveria ser).
Para "ver" a situação "de fora", carreguei o openSUSE (1 semana mais tarde) — e descobri que persiste uma cópia de /run/media/$USER/ na pasta /var. — Aliás, descobri que isso também ocorre em outras distros (eu nunca tinha notado).
Lá estavam os tais pontos de montagem pertencentes ao Administrador. — Portanto, de nada adiantariam meus esforços para corrigir isso por comandos como, p.ex., # chown 1000:1000 /run/media/#USER/[mountpoint] dentro do próprio Redcore — pois no boot seguinte a situação anterior seria restabelecida a partir da cópia na pasta /var.
Então, executei o comando chown 1000:1000 nos pontos de montagem, nesse "backup" guardado na pasta /var do Redcore — a partir do openSUSE.
Reiniciei o computador — o Redcore Linux montou, automaticamente, todas as partições adicionais (dessa vez, pelo menos!) — e até agora não explodiu nada.
 |
| Recebendo fotos do celular pelo KDE Connect |
Ainda na primeira hora do dia 13, liberei o KDE Connect para o celular, para poder baixar logo as fotos da instalação e da atualização inicial:
# history
52 2022-06-13_00-50-07 iptables -I INPUT -p tcp --dport 1714:1764 -j ACCEPT
53 2022-06-13_00-50-20 iptables -I INPUT -p udp --dport 1714:1764 -j ACCEPT
 |
| Abrir pasta com o KRename |
Configurei uma associação de arquivos para o KRename ser a segunda opção de "abrir pastas", no menu de contexto do Dolphin — o que facilita renomear rapidamente todas as fotos recém-baixadas. — Renomeio com o mesmo padrão "data+hora" que uso nas capturas de tela e no histórico de comandos, o que facilita reuni-los em sequência cronológica (numa pasta ou em um arquivo TXT).
 |
| Colocando o ícone do Redcore Linux no Menu |
Substituí o ícone do Menu, quase invisível, pelo do Redcore, em vermelho vivo. — Habilitei no Menu a seção de aplicativos e arquivos usados recentemente. — Desabilitei a "expansão" de sua Busca, que incluía Favoritos (Bookmarks), Arquivos e Emails.
 |
| Substituição do Task Manager pelo Icons-only Task Manager |
Substituí o Gerenciador de Tarefas tradicional por outro só de ícones.
Tempos depois, desabilitei o “Mute” nos ícones do Chrome e do WhatsChrome.
Reconfigurei o "Zoom In", de 1,2x para 3,0x de cada vez — o que facilita capturar detalhes do Conky sem perder tempo.
 |
| Habilitando o Blur |
Habilitei o Blur, que por algum motivo estava inativo. — Com isso, o Menu do Maia Transparent ficou legível.
 |
| Agendamento do script para 10 minutos após o boot |
Corrigi o bash script RAM.sh (copiado de outra distro) — que salva informações do uso de Memória — e agendei para ser executado 10 minutos após o boot. O tempo de ir buscar um café e ver se o mundo ainda está lá fora.
 |
| Linhas longas demais nas mensagens do Sisyphus |
Toda vez que eu abria a sessão do Kate com as anotações sobre o Redcore, eu recebia uma mensagem de "linha longa demais". — Sim, o Sisyphus colocou as pastas, os nomes e as versões de todos aqueles 984 pacotes da atualização inicial em uma única linha de 28.664 caracteres, com 2 espaços em branco separando uns dos outros.
Selecionei aquela linha descomunal — basta Shift-End (2 vezes) — cortei e colei num arquivo provisório, para ver o que se poderia fazer com aquilo.
Nesses casos, o Google me manda logo para o Stackoverflow — a partir dali, pesquisei o comando sed para mais dicas — e acabei resolvendo o problema:
$ sed -i.backup 's/ /\n/g' try1.txt
Em resumo, eu queria substituir cada 2 espaços por uma quebra de linha — e finalmente consegui uma bela lista de 984 linhas, que o Kate / KWrite aceita com um sorriso.
 |
| Desabilitando a detecção de outras distros pelo Grub do Redcore |
No /etc/default/grub, retirei os parâmetros quiet splash (para ver o que acontece no boot) — adicionei uma linha GRUB_DISABLE_OS_PROBER="true" (pois não preciso que ele perca tempo detectando outras distros) — e executei a atualização do Grub, para que essas mudanças sejam incorporadas ao Grub do Redcore Linux.
Naturalmente, mais tarde reinicializei o computador e carreguei o openSUSE, cujo Grub é meu Menu de inicialização. — Ao atualizar o Grub do openSUSE, ele “lê” o Grub das outras distros, e incorpora essas mudanças que fiz no Redcore Linux.
 |
| Personalização do Gimp |
14 Jun 2022 - Ao iniciar a sistematização deste relato, personalizei o Gimp. — Desmembrei a "janela única", descartei a caixa da direita, simplifiquei o Toolbox (à esquerda), adicionei a ele a aba Camadas, apliquei um Tema escuro, criei 2 atalhos (X para Crop, S para salvar como) etc. — e salvei logo as Opções de Ferramentas, para não perder todas essas configurações se faltar luz antes de fechá-lo.
 |
| Habilitando a partição Swap |
15 Junho 2022 - Finalmente lembrei de habilitar a partição Swap. — Como não sei quais parâmetros o Redcore Linux prefere, analisei os arquivos /etc/fstab das outras distros e adotei os parâmetros mais "populares" entre elas — em especial, PCLinuxOS, Slackare e MX Linux (o Void usa none swap sw 0 0):
[PATH] /Warehouse/Byteria/Hardware--Partitions/etc-fstab/2022-06-13_Redcore/
$ cat * | grep swap
01 UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96 swap swap defaults 0 0
02 UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96 none swap defaults 0 0
03 UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96 none swap sw 0 0
04 UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96 swap swap defaults 0 0
05 UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96 none swap sw 0 0
06 UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96 swap swap defaults 0 0
07 UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96 swap swap defaults 0 0
08 /dev/sdb16 swap swap defaults 0 0
09 UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96 none swap sw 0 0
10 UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96 none swap defaults 0 0
12 UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96 swap swap defaults 0 0
17 Jun 2022 - O Night Colour não detectou minha localização. — Tive de inserir manualmente Latitude e Longitude — que felizmente tenho sempre à mão.
CPU e Temperatura
 |
| CPU a 100ºC ao instalar KStars |
20 Jun 2022 - A instalação do Foliate levou cerca de 7 minutos, com alto uso de CPU, elevadas temperaturas, chegando em alguns momentos a 100ºC — e a ventoinha do cooler uivando como uma alma penada.
A instalação do KStars demorou cerca de 7 minutos — com a ventoinha do cooler uivando a todo vapor — e longos períodos a 100ºC.
Uma pesquisa rápida apresentou vários tópicos no fórum do Gentoo — de pessoas perguntando se temperaturas de 100ºC são normais, ao compilar pacotes — e vários colegas respondendo que o normal é ficar na faixa de 50ºC ~ 60ºC.
Trocar a pasta térmica e limpar a ventoinha do cooler não é um bicho-de-7-cabeças — mas os registros do início de 2020 (quando as peças do computador tinham acabado de sair das embalagens) mostram que eu obteria uma redução de, no máximo, 11ºC, e provavelmente nem metade disso. — Portanto, a solução deveria estar em outro lugar.
 |
| Void, PCLinuxOS e KDE Neon inativos até 10 minutos após o boot |
O exame de mais alguns registros mostrou que várias das minhas distros ficam pouco acima de 800 ou 900 MHz, quando em repouso — e vão a 3.900 ~ 4.000 MHz numa fração de segundo, quando necessário.
Isso está de acordo com a velocidade-base de 800 MHz e “Intel Turbo Boost” até 4.100 MHz, nas especificações. — Ou, segundo o inxi: “Speed: 800 MHz | min / max: 800 / 4100 MHz (...)”.
 |
| Slackware e Redcore Linux inativos até 10 minutos após o boot |
Uma exceção era o Slackware, que costuma oscilar sempre nas proximidades de 4.000 MHz — e pelo que vejo agora, também o Redcore Linux. — Mas quando a compilação de pacotes começa a aquecer demais os núcleos, o Redcore reduz a frequência para 3.600 ~ 3.700 MHz, mantendo o limite de 100ºC.
 |
| Compilação sem “Intel Turbo Boost” e sem aquecimento, no Redcore |
Alguma coisa no fórum do Gentoo me levou a desativar o “Intel Turbo Boost” no UEFI Bios Setup, para testar o comportamento.
Depois disso, o Redcore já iniciou na frequência de 2.900 MHz e apresentou temperaturas levemente menores do que em todas as sessões da última semana (detalhe do alto, acima).
Removi o Foliate, expurguei os pacotes órfãos, e tornei a instalar o Foliate:
# history
314 2022-06-20_22-15-20 date; sisyphus uninstall foliate; date
316 2022-06-20_22-17-38 date; sisyphus autoremove; date
318 2022-06-20_22-19-45 date; sisyphus install foliate --ebuild; date
Dessa vez, a instalação do Foliate levou cerca de 8 minutos e meio — as temperaturas ficaram na faixa de 60ºC ~ 70ºC (detalhe ao centro, acima), e a frequência se manteve em 2.900 MHz, sem redução alguma. — Agora, sim, a limpeza da ventoinha do cooler e a troca da pasta térmica poderão reduzir essas temperaturas para a faixa de 50ºC ~ 60ºC.
A partir dessas observações, minhas leituras sobre o Redcore Linux (e o Gentoo) ganham mais um sentido. — Se entendi direito, pode-se reduzir isso por meio de algumas flags aqui e ali.
Até hoje, eu nunca tinha pensado em desabilitar o “Intel Turbo Boost”. — Mas não jogo, nem costumo fazer processamentos intensivos — exceto, agora, as compilações do Redcore.
Por princípio, o Turbo é eficiente em reduzir a frequência para manter a Temperatura máxima em 100ºC — e com isso posso ganhar alguns minutos nas grandes atualizações — mas o uivo desesperado da ventoinha do cooler é estressante demais para o meu gosto.
Essa foi a melhor decisão, como percebi ao mexer nas flags USE — e um dia, a recompilação de 35 pacotes demorou 3 horas 10 minutos, com a CPU no máximo a maior parte do tempo. — Mal se ouviam pequenas acelerações da ventoinha do cooler — o que é muito mais confortável do que ganhar 20 minutos, com um uivo desesperado, por 3 horas.
Apenas aproveitei para navegar na web e botar vários assuntos em dia, como se nada estivesse acontecendo.
Dolphin
 |
| Painel Informações (F11) do Dolphin, no KDE Neon |
16 Junho 2022 - Dolphin sem a opção de exibir o painel “Informações” (F11), do lado direito, foi uma "novidade" difícil de lidar, nas primeiras semanas de uso do Redcore Linux.
Nunca vi essa falha, nas 25 ou 30 distros que já instalei — nem mesmo, quando experimentei instalar o Dolphin em sessões Live de distros sem KDE.
 |
| Ferramenta "Mostrar dicas" do Dolphin, no KDE Neon |
Imaginei compensar isso com a ferramenta "Mostrar dicas", que exibe uma miniatura e os dados da foto ou imagem — o que ainda não seria o ideal — mas esse recurso também estava ausente no Dolphin do Redcore Linux.
 |
| Dolphin com os módulos de pré-visualização de arquivos |
Instalei os módulos de pré-visualização de arquivos no Dolphin — para os tipos de arquivo que utilizo* — mas isso não consertou o Dolphin (como, aliás, não era mesmo de se esperar).
* Deixei para mais tarde apenas o Marble, que deveria habilitar a pré-visualização de arquivos KML e KMZ — mas quando instalei (dias depois), não deu resultado. — Instalei até o kdegraphics-meta (para me certificar de que não faltasse nada), sem sucesso.
 |
| Dolphin no modo de visão em ícones |
Tentei usar o modo de visão em Ícones, mas não consegui lidar com isso: — Nomes dispersos, em linhas quebradas — e um enorme desperdício de espaço.
Naturalmente, a vida continua — e completei 2 ou 3 semanas de uso contínuo do Redcore Linux — mas a vontade de reiniciar a máquina e carregar outra distro era uma constante.
 |
| Teste improvisado de USE flags no Redcore Linux |
17 Jul 2022 - Depois de vários dias fora do Redcore (para esfriar a cabeça), pesquisei “dolphin gentoo panel” — e a solução apareceu logo no primeiro link, do Fórum do Gentoo: — Habilitar a flag (sinalizador) USE “semantic-desktop”.
Meus problemas estariam terminados, se eu já tivesse aprendido tudo sobre o Sisyphus, o Portage / emerge, flags USE etc. — Mas, como eu ainda não tinha lido quase nada sobre isso, improvisei uma solução capenga, só para testar. — Adicionei a flag num arquivo que diz expressamente “Não edite”, e apelei para um comando emerge achado em alguma página:
# cat /etc/portage/package.use/00-kde-apps.package.use | grep dolphin
kde-apps/dolphin thumbnail
# This file has been automatically generated, do not edit.
kde-apps/akonadi -mariadb
kde-apps/ark zip
kde-apps/dolphin thumbnail semantic-desktop
kde-apps/k3b encode mad taglib
kde-apps/kdecore-meta -webengine -webkit
kde-apps/kdenetwork-meta dropbox -webengine
kde-apps/kdesdk-meta -python
kde-apps/krfb -wayland
kde-apps/okular epub
# emerge --changed-use kde-apps/dolphin
 |
| Recompilação do Dolphin pelo emerge |
A recompilação do Dolphin levou menos de 2 minutos.
 |
| Painel “Informações” (F11) no Dolphin do Redcore Linux |
E voilà! — O Dolphin recompilado finalmente ofereceu a opção de exibir o painel “Informações” (F11) — com a pré-visualização de pastas e arquivos.
 |
| Opção “Mostrar dicas”, após recompilar o Dolphin |
De brinde, o Dolphin recompilado também passou a oferecer a opção “Mostrar dicas” — que agora não é mais necessária.
Isso está longe de ser “o procedimento correto” — e talvez seja desfeito em alguma atualização, se o arquivo 00-kde-apps.package.use reverter ao padrão.
Mas foi o suficiente para comprovar que encontrei o caminho — e me deu a motivação prática que faltava para aprender mais sobre as flags USE.
 |
| Dolphin ainda sem dados Exif no Redcore Linux |
Ainda falta solucionar a falta de dados Exif no painel “Informações” do Dolphin — mas isso é bem menos incômodo, no meu dia-a-dia.
 |
| Dados Exif no Gwenview do Redcore Linux |
O KDE Plasma está habilitado, sim, a exibir os dados Exif. — No Gwenview, abrir seu painel lateral (F4) e clicar em “Show more details”. — Só falta levar essa capacidade para o Dolphin.
Flags USE
 |
| O arquivo de configuração do Portage que eu não devia ter editado |
A maior dificuldade que deparei, para lidar com as flags USE, reside nas “dualidades” Redcore / Gentoo, e Portage / Sisyphus. — Aliás, a dualidade Portage (gerenciador de pacotes) / emerge (comando do Portage) também não ajuda o novato.
O Redcore tem pouquíssima documentação, pouquíssimos participantes no fórum, e não existe man sisyphus — só um sisyphus --help bem resumido.
É até compreensível que a Ajuda seja resumida — afinal, Sisyphus é feito, mesmo, para simplificar a vida do novato com o Portage / emerge — que ele usa (não substitui), quase como se ele fosse apenas uma coleção de alias simplificados para comandos emerge.
Só que toda a (ótima) documentação sobre as flags USE ensina a usar comandos emerge — e se refere à estrutura de arquivos de configuração no Gentoo. — Por isso, a cada passo, tive de tentar encontrar, no Redcore, os arquivos e comandos equivalentes aos indicados na documentação do Gentoo.
Além disso, a estrutura de arquivos de configuração do Gentoo pode ser alterada pelo usuário — sua própria documentação sugere isso — e os comandos indicados não são aplicáveis ao Redcore, sem adaptação:
Se package.use for pré-existente como um diretório (em oposição a um único arquivo), os pacotes podem ter seus sinalizadores USE modificados simplesmente criando arquivos no diretório package.use/
O importante é notar que existe uma ordem inversa de precedência — onde os últimos se sobrepõem aos anteriores — de modo que o usuário não precise editar os arquivos-padrão, pois valerá a personalização o que fizer mais adiante:
- Configuração padrão de USE declarada nos arquivos make.defaults que fazem parte do seu perfil
- Configuração USE definida pelo usuário em /etc/portage/make.conf
- Configuração USE definida pelo usuário em /etc/portage/package.use
- Configuração USE definida pelo usuário como variável de ambiente (temporária)
Porém, foi justamente ao editar o arquivo sugerido no item nº 3, que encontrei um aviso de “Não edite”, pois foi “gerado automaticamente”. — Uma adaptação introduzida pelo Redcore?
 |
| O arquivo de configuração do Sisyphus para o usuário editar |
Só no final da pasta, descobri o caminho sugerido pelo Redcore: — um arquivo sisyphus-custom.package.use — na verdade, um link para onde ele realmente está, na estrutura de arquivos de configuração do Sisyphus.
Aliás, a própria pasta /etc/portage é um link para /opt/redcore-build/conf — onde estão as opções intel, arm, cross. — Um luxo!
# ls -o /etc/portage/package.use/ | grep 'kde\|custom'
-rw-r--r-- 1 root 336 Jul 22 15:04 00-kde-apps.package.use
-rw-r--r-- 1 root 336 Jul 18 12:16 00-kde-apps.package.use-CUSTOM
-rw-r--r-- 1 root 113 Jul 22 15:04 00-kde-frameworks.package.use
-rw-r--r-- 1 root 297 Jul 10 09:54 00-kde-plasma.package.use
lrwxrwxrwx 1 root 41 Oct 18 2021 10-sisyphus-custom.package.use -> /etc/sisyphus/sisyphus-custom.package.use
# ls -o /etc/portage
lrwxrwxrwx 1 root 38 Dec 19 2020 /etc/portage -> /opt/redcore-build/conf/intel/portage/
# ls -o /opt/redcore-build/conf
total 12
drwxr-xr-x 3 root 4096 Oct 18 2021 arm
drwxr-xr-x 3 root 4096 Oct 18 2021 cross
drwxr-xr-x 3 root 4096 Oct 18 2021 intel
# ls -o /etc/sisyphus/
total 12
lrwxrwxrwx 1 root 41 Jul 17 09:51 mirrors.conf -> /etc/sisyphus/sisyphus-mirrors-amd64.conf
-rw-r--r-- 1 root 0 Jul 14 07:34 sisyphus-custom.env.conf
-rw-r--r-- 1 root 0 Jul 14 07:34 sisyphus-custom.make.conf
-rw-r--r-- 1 root 0 Jul 14 07:34 sisyphus-custom.package.accept_keywords
-rw-r--r-- 1 root 0 Jul 14 07:34 sisyphus-custom.package.env
-rw-r--r-- 1 root 0 Jul 14 07:34 sisyphus-custom.package.license
-rw-r--r-- 1 root 0 Jul 14 07:34 sisyphus-custom.package.mask
-rw-r--r-- 1 root 0 Jul 14 07:34 sisyphus-custom.package.unmask
-rw-r--r-- 1 root 410 Jul 22 12:13 sisyphus-custom.package.use
-rw-r--r-- 1 root 1171 Oct 18 2021 sisyphus-mirrors-amd64.conf
-rw-r--r-- 1 root 1466 Jul 14 07:34 sisyphus-mirrors-arm64.conf
Fiquei sem saber o que colocar no arquivo sisyphus-custom.package.use — que veio vazio (nem 1 linha de dica!) — se seu “equivalente” no Handbook do Gentoo / Portage é uma pasta package.use/, com nada menos que 57 arquivos.
“Use a lógica!” — É tudo que um novato não deve fazer, pois ainda ignora a “lógica” de uma distro, com a qual falta se familiarizar. — Esta é a origem de 11 em cada 10 desastres.
Copiar para ele centenas de linhas, de dezenas de arquivos? — Transformá-lo numa pasta (como?) e povoá-la com dezenas de arquivos, imitando seu equivalente no Portage?
 |
| Experiências com o arquivo sisyphus-custom.package.use |
Acabei me inspirando em um arquivo postado no Fórum Gentoo — feito para não ter de editar outros arquivos de configuração do Portage — e comecei a fazer minhas experiências:
# /etc/portage/package.use/10-sisyphus-custom.package.use
# links to:
# /etc/sisyphus/sisyphus-custom.package.use
######################## Global #########################
*/* semantic-desktop
*/* -nvidia radeonsi radeon amdgpu
*/* -cups
*/* -gnome-keyring
*/* -mysql
*/* -sqlite
*/* -wayland
*/* -samba
######################## Local ##########################
kde-apps/dolphin thumbnail semantic-desktop
Na primeira parte (Global), habilitam-se ou bloqueiam-se flags (sinalizadores) USE para todos os pacotes que possam usá-las. — Na segunda parte (Local), para pacotes específicos.
É redundante colocar semantic-desktop especificamente para o Dolphin — afinal, já habilitei globalmente — mas “o que não mata, engorda”, como dizia a minha avó.
Para aplicar as mudanças, executei o comando sisyphus upgrade --ebuild — em vez de algum comando emerge cheio de parâmetros e opções.
Mas antes, atualizei o sistema (para não misturar as coisas). — Em seguida, editei esse arquivo de configuração pessoal — e tornei a atualizar (verificando quais pacotes seriam afetados, antes de prosseguir).
 |
| Recompilação de pacotes após alterar flags USE no Redcore Linux |
Na primeira experiência, habilitei globalmente */* semantic-desktop e desabilitei globalmente (hífen ou sinal negativo) */* -nvidia -cups -gnome-keyring -mysql -sqlite -wayland. — O comando sisyphus upgrade --ebuild propôs “mesclar” (merge) 35 pacotes — e o processo levou cerca de 3 horas 10 minutos (19:02 ~ 22:12), com uso de 100% de CPU a maior parte do tempo.
Duas semanas depois, minha atualização semanal se viu bloqueada, porque alguns pacotes exigiam as flags USE cups e sqlite. — Levei mais duas semanas para conseguir decifrar as mensagens de erro — e nesse meio tempo mais alguns pacotes já exigiam habilitar também a flag USE wayland:
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
(...)
The following USE changes are necessary to proceed:
(see "package.use" in the portage(5) man page for more details)
# required by kde-plasma/xdg-desktop-portal-kde-5.25.4::gentoo
# required by kde-plasma/plasma-meta-5.25.4::gentoo
# required by @selected
# required by @world (argument)
>=dev-qt/qtprintsupport-5.15.5-r1 cups ----- USE flags !!!
# required by kde-plasma/kwin-5.25.4-r1::gentoo
# required by kde-plasma/plasma-desktop-5.25.4::gentoo
# required by kde-plasma/plasma-meta-5.25.4::gentoo
# required by @selected
# required by @world (argument)
>=media-libs/mesa-22.1.5 wayland ----- USE flags !!!
# required by app-portage/sisyphus-4.2107.0-r5::redcore
# required by @selected
# required by @world (argument)
>=dev-lang/python-3.10.6 sqlite ----- USE flags !!!
Liberei de volta essas 3 flags USE — e finalmente consegui atualizar o sistema:
# /etc/portage/package.use/10-sisyphus-custom.package.use
# links to:
# /etc/sisyphus/sisyphus-custom.package.use
######################## Global #########################
*/* semantic-desktop
*/* -nvidia radeonsi radeon amdgpu
*/* -gnome-keyring
*/* -mysql
*/* -samba
######################## Local ##########################
kde-apps/dolphin thumbnail semantic-desktop
Redcore 2201
 |
| Versão anterior do Sisyphus, incapaz de processar tantos pacotes |
Só em Outubro foi lançada a nova imagem ISO Redcore Linux Hardened 2201 (=2022 nº 1), com direito a Notas de lançamento, notícias nos portais, artigos nos blogs sobre “como instalar”, avaliações, comentários nos fóruns etc. — o que deve impulsionar novo aumento de cliques no ranking do Distrowatch ao longo das próximas semanas — mas por se tratar de uma distro rolling-release, não vi necessidade de fazer nova instalação.
O lançamento foi anunciado em 5 Outubro, após um curto período de "calmaria" (nenhuma atualização no Domingo anterior, 2 Outubro) — e no Domingo seguinte, 9 Outubro, o Sisyphus não conseguiu, sequer, processar a quantidade de pacotes a serem atualizados e suas dependências. — Rodou mais de 30 minutos, sem chegar a qualquer conclusão.
O Fórum do Redcore tem apenas um punhado de membros (o captcha, para se registrar, é desanimador!), e raríssimas postagens. — Talvez por isso, o Google falha vergonhosamente, quando se pesquisam palavras-chave dentro da "última semana". — Relendo as Notas de lançamento, intuí neste bugfix a possível solução:
bugfix: sisyphus não fica mais preso quando a lista de dependências é muito grande
Reinstalei então o sisyphus (versão atualizada):
# date; sisyphus install sisyphus --ebuild; date
Mon 10 Oct 09:58:53 -03 2022
These are the binary packages that would be merged, in order:
sys-apps/portage-3.0.38.1 app-portage/sisyphus-4.2209.1 app-portage/sisyphus-qt-4.2209.1
Total: 3 binary package(s)
Would you like to proceed? [y/N] y
(...)
Mon 10 Oct 10:00:49 -03 2022
Depois disso, o Sisyphus conseguiu processar todas as atualizações disponíveis, com todas as suas dependências: — Nada menos que 1481 pacotes binários + 12 ebuilds para compilar.
# date; sisyphus upgrade --ebuild; date
Mon 10 Oct 10:02:56 -03 2022
These are the binary packages that would be merged, in order:
sys-kernel/linux-headers-5.19
(...)
app-vim/gentoo-syntax-2
Total: 1481 binary package(s)
These are the source packages that would be merged, in order:
app-eselect/eselect-repository-13 www-client/links-2.28 gui-libs/libhandy-1.8.0 net-libs/webkit-gtk-2.36.7-r1 app-crypt/pinentry-1.2.1-r1 dev-vcs/git-2.38.0 media-video/ffmpeg-4.4.2 media-video/vlc-3.0.17.4-r1 kde-frameworks/baloo-5.98.0 sci-astronomy/kstars-3.6.1 kde-apps/dolphin-22.08.1 kde-plasma/plasma-workspace-5.25.5-r4
Total: 12 source package(s)
Would you like to proceed? [y/N] y
(...)
Mon 10 Oct 13:02:27 -03 2022
Essa atualização massiva levou 3 horas para ser baixada, compilada e instalada (das 10:02 às 13:02) — enquanto eu desempenhava minhas atividades normais na internet, ouvindo música, fazendo anotações, capturas de tela etc. — o que está dentro da experiência observada nesta máquina, ao longo dos últimos 4 meses.
No final, o Sisyphus apresentou 522 linhas de mensagens esotéricas — que copiei para meu arquivo de anotações, para eventuais consultas, no futuro — pois até o momento sou incapaz de compreender ou tirar proveito da maior parte.
Percebi que o arquivo /boot/grub/grub.cfg não tinha sido automaticamente atualizado — então tratei de atualizá-lo manualmente — para ser lido pelo Grub do openSUSE, que gerencia meu Menu de inicialização:
# date; grub2-mkconfig -o /boot/grub/grub.cfg; date
Mon 10 Oct 14:12:52 -03 2022
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/redcore/theme.txt
Found linux image: /boot/vmlinuz-5.14.21-redcore
Found initrd image: /boot/initrd-5.14.21-redcore
done
Mon 10 Oct 14:12:58 -03 2022
Ao final dessa mega-atualização, nenhuma alteração nos aspectos "visíveis" a um usuário leigo. — O Kernel e o KDE Plasma permanecem nas mesmas versões de antes — o que parece prudente, para não complicar a tarefa dos mantenedores da distro. (Já vi outras distros agirem assim).
 |
| Pacotes da seção sys-kernel instalados no Redcore |
É verdade que foi instalado um pacote linux-headers-5.19 — mas o único Kernel instalado e configurado, até agora, continua sendo o 5.14.21. — Sinal de que já tenho mais uma coisa para tentar aprender, e tomar as eventuais providências.
“There is NOT at least 6400 MiB disk space at...”
 |
| Sisyphus exige mais espaço em disco para o Redcore Linux |
Apenas 4 meses depois de instalado, o Redcore Linux deixou de caber na partição de 30 GiB — apesar de eu “limpar” regularmente o cache de pacotes baixados e já instalados — dentro das possibilidades oferecidas pelas ferramentas de cada distro.
No Redcore Linux, a “simplicidade“ do Sisyphus oferece poucos recursos para isso — basicamente, # sisyphus autoremove — que na verdade, não limpa o cache, mas apenas remove pacotes deixados órfãos.
Por isso, preciso recorrer a comandos do emerge — que eu não queria explorar agora, para não complicar o aprendizado, nesta fase ainda inicial. — Por exemplo, o # emerge --depclean, ou o # eclean-dist -dv, e até mesmo o # emerge --update --newuse --deep --with-bdeps=y @world (que não é para isso, mas sempre ajuda a limpar um pouco).
Mas não tem jeito — o espaço ocupado em disco aumenta a cada semana, com uma rapidez que eu ainda não tinha visto em outras distros. — Tenho certeza de que há cada vez mais pacotes em cache ocupando espaço em disco, mas nunca encontrei um modo de eliminá-los, sem partir para a eliminação manual, peça por peça, “no olhômetro” e “no chutômetro” — ou seja, sem o risco de escangalhar o sistema por pura ignorância.
Finalmente, em 23 Outubro 2022, a atualização foi abortada por falta de espaço — com a mensagem de que “There is NOT at least 6400 MiB disk space at /var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp”.
Eu já tinha driblado um problema semelhante no Manjaro simplesmente mudando o “Build directory” do AUR para uma pasta “ManjaroTemp” na partição de dados Warehouse (pertencente ao “Usuário comum”) — mas no Redcore eu teria de “inventar” meu próprio modo de fazer algo similar, sem a ajuda de um “Pamac-GUI” e sem ter encontrado na web nenhuma dica neste sentido. — A alternativa mais “simples” era simplesmente aumentar a partição do Redcore Linux, o que exigia “mover” a partição do MX Linux mais para o final, para abrir espaço no SSD (contíguo à partição do Redcore).
Deixei o assunto no quarto-dos-fundos da cabeça por algumas semanas — afinal, a imagem ISO de instalação, defasada em 8 meses, provou que ficar 15 ou 30 dias sem atualizar o Redcore não seria tão grave assim — mas nesse meio tempo outros 2 pacotes passaram a exigir ainda mais espaço, conforme sucessivas anotações, a cada tentativa de “limpeza” do cache de pacotes:
$ cat * | grep 'There is NOT at least'
* There is NOT at least 6400 MiB disk space at "/var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp"
* There is NOT at least 6400 MiB disk space at "/var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp"
* There is NOT at least 6400 MiB disk space at "/var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp"
* There is NOT at least 6400 MiB disk space at "/var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp"
* There is NOT at least 6400 MiB disk space at "/var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp"
* There is NOT at least 6400 MiB disk space at "/var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp"
* There is NOT at least 15897 MiB disk space at "/var/tmp/portage/dev-lang/rust-1.65.0/temp"
* There is NOT at least 7 GiB disk space at "/var/tmp/portage/dev-qt/qtwebengine-5.15.5_p20220618/temp"
* There is NOT at least 15897 MiB disk space at "/var/tmp/portage/dev-lang/rust-1.65.0/temp"
* There is NOT at least 7 GiB disk space at "/var/tmp/portage/dev-qt/qtwebengine-5.15.5_p20220618/temp"
E cada uma dessas tentativas significa uma “atualização abortada” — o que deixa sequelas, como acabei por descobrir.
 |
| Pasta na Memória RAM para compilações do Portage |
Uma terceira alternativa que encontrei, seria criar uma pasta temporária na Memória RAM — mas como tenho apenas 1 pente de 16 GB, isto só serviria para agilizar compilações de, no máximo, 7 GB — pois eu teria de criar um “arquivo de exceções” para deixar de fora, por exemplo, os 15 GB necessários no caso do Rust (se é que preciso dele... mas isso já é uma outra estória: não encontrei uma resposta “para as massas”).
 |
| Aumentando a partição do Redcore, de 30 para 60 GiB |
Para aumentar a partição do Redcore Linux (Linux11), copiei a partição do MX Linux (Linux12) para o espaço disponível depois dele — e deletei o original, deixando 30 GiB de espaço não-utilizado entre as duas distros. — Com isso, pude ampliar (grow) a partição do Redcore para 60 GiB.
Na noite de Domingo, 4 Dezembro 2022, finalmente consegui concluir a tão adiada atualização — ou, “quase concluir”. — Agora, a atualização não aborta mais por falta de espaço em disco (ufa!), mas... por outros motivos.
Em uma sequência de 5 execuções de # sisyphus upgrade --ebuild — alternando Restart, autoremove, comandos emerge — consegui alguns avanços parciais:
16:36 ~ 18:18 864 binary packages 11 source packages "n" errors
-- autoremove "n" errors
19:21 ~ 19:24 just install -- Chrome 107
19:37 ~ 19:51 229 binary packages 155 source packages "n" errors
19:54 ~ 21:47 385 binary packages 12 source packages "n" errors -- Chrome 108
21:58 ~ 22:22 166 binary packages 10 source packages "n" errors
162 binary packages 10 source packages [y/N] No, sir!
Como eu precisava pesquisar no Google Chrome (e ele reclamava o tempo todo), acabei por reinstalar, e passou para a versão 107. — Após mais 2 tentativas de atualização geral, notei que o Chrome havia passado para a versão 108 — e outros pacotes também avançaram 2 versões, ao longo dessas tentativas.
Porém vários pacotes “atualizados” nunca entraram em vigor. — O Qt passou de 5.15.5 para 5.15.7, mas o resto do KDE, seus aplicativos e o Frameworks continuam nas versões anteriores a 23 Out. 2022 — apesar de inúmeros pacotes com versões mais novas terem sido baixados e (aparentemente) instalados.
Ao que parece, há muitos pacotes antigos que conflitam com as dependências exigidas — y otras cositas más.
Uma das mensagens mais interessantes é “Task was destroyed but it is pending”.
Em resumo, o Sisyphus quer, ou precisa, concluir uma série de tarefas que ficaram pendentes (de uma atualização abortada), mas aquelas “tarefas” foram deletadas.
\\\\
Por que não desistir?
Com 12 distros instaladas em “multiboot”, posso me dar ao luxo de insistir com algumas que ainda não domino — casos do Slackware, do Void e, agora, do Redcore — para aprender mais, nas horas vagas.
O Arch Linux, o Debian testing, o Mageia, o Manjaro e o MX Linux (Debian stable) oferecem todas as ferramentas de que preciso, a qualquer momento — em resumo: Google Chrome, GoogleEarth “Desktop”, WhatsChrome (enquanto não acaba), LibreOffice, Gimp, Foliate, VLC (ou outro), e uma penca de aplicativos KDE.
Não sou nenhum sabe-tudo; apenas, um usuário “médio, enxerido” — e já faz mais de 12 meses que acabo usando quase sempre o Arch Linux. — A essa altura do aprendizado, o Void me parece ser a próxima meta; e o Redcore, a meta seguinte.
Nesse quadro, acho mais importante “não quebrar de vez” o Redcore — ir devagar, pesquisar, ler, anotar tudo, voltar a ler, tentar de novo, com calma — do que ficar obcecado em resolver tudo de um dia para o outro, na base do “ou vai, ou racha”, sem ter, ainda, aprendido o suficiente para isso.
“Reinstalar” é o último recurso — pois significa desistir de entender, aprender e consertar a instalação.
Por que Redcore Linux?
 |
| Sabayon instalado (Dez. 2018 ~ Jan. 2020) no meu antigo PC desktop |
Não sou "profissional de TI", mas apenas um usuário enxerido — e manter várias distros em dualboot (ou multiboot) é um modo de ter alternativas prontas para uso imediato, em caso de catástrofe local ou remota (*). — Para poder passar de uma distro a outra em 2 minutos e continuar trabalhando sem perda de tempo, uso sempre KDE e procuro aplicar sempre as mesmas configurações (incluindo um Conky mais informativo do que decorativo).
(*) Minha única “catástrofe” real, em 15 anos com Linux, ocorreu em 2017, e não foi só uma: foram duas, uma após outra. — Uma distro “de reserva” ficou meio bichada após um upgrade; e semanas depois deletei outra, por pura distração.— Desde então, já instalei umas 20 distros (até escolher as 12 atuais), sem nenhum outro desastre irreversível. Certa vez, perdi todo o KDE no Devuan, mas foi possível reverter. Agora, fiquei alguns dias sem conseguir carregar o MX Linux (mudou o UUID da partição!), mas também foi possível recuperá-lo. Coisas assim não são “desastres” de verdade.
Limitei minha coleção a 12 distros — atualmente, 2 do ramo Debian (Debian + MX Linux); 1 do sub-ramo Debian-Buntu (KDE Neon); 2 do ramo Arch (Arch + Manjaro); 2 do ramo Mandrake (PCLinuxOS + Mageia); além de openSUSE, Fedora, Slackware e Void, de seus próprios ramos da árvore Linux. — Isso permite me familiarizar, no dia-a-dia, com um leque amplo de distros, as mais diferentes umas das outras: empresariais ou comunitárias, mais completas ou mais enxutas, com diferentes abordagens, filosofias, gerenciadores de pacotes, sistemas init etc.
Em cada "ramo" da árvore Linux, procuro começar por uma distro mais amigável, para me familiarizar, e mais tarde avanço (ou não) para o mais complexo.
Foi mais ou menos o que fiz no caso do Arch Linux. Primeiro, instalei o Manjaro, no início de 2017 — e 6 meses depois instalei o Arch pelo Revenge (atual Zen Installer), para me familiarizar melhor. — Só 2 anos depois, enfrentei a instalação (em Bios-MBR, depois em UEFI-GPT), pelo "modo Arch", também conhecido como "modo BTW" ou "modo RTFM".
Com aquela experiência, me senti pronto para instalar o Void (em Bios-MBR, depois em UEFI-GPT), logo no outro mês. — O modo de instalação "construir peça por peça" tinha deixado de ser um bicho-de-7-cabeças, para mim (apesar de o Void não ter nada a ver com Arch!). — O instalador entregava o sistema básico, e bastava acrescentar o KDE Plasma.
Mas o Gentoo exige muito mais tempo e energia do que estou disposto a investir, por enquanto.
Comecei pelo Sabayon Linux, instalado no final de 2018 no meu antigo PC desktop, mas ele foi descontinuado pouco depois, em favor do Mocaccino OS — com o qual ainda não consegui me entender — e acabei escolhendo o Redcore Linux, em Junho 2021, para continuar experimentando uma distro do ramo Gentoo, antes de me arriscar (ou não!) no Gentoo propriamente dito.
 |
| Hits nas páginas do Distrowatch sobre as distros Gentoo-based |
Redcore Linux era a distro do ramo Gentoo que parecia despertar mais interesse (na média dos 6 meses anteriores), entre os visitantes do Distrowatch, em Junho do ano passado. — Isto não significa maior ou menor número de usuários efetivos de uma distro mas, tão somente, maior ou menor número de acessos às páginas de cada distro no próprio Distrowatch — e isso flutua muito, aumentando logo após cada lançamento e diminuindo depois. O Redcore Linux 2101 (=2021 nº 1) tinha acabado de ser lançado, e é normal que mais pessoas clicassem na página do Distrowatch sobre a distro, para verificar mais detalhes. Em meados de 2022, passados 8 meses do último lançamento, baixou para o 107º lugar no ranking geral (média de acessos nos últimos 6 meses), e foi superada pelo CloudReady (que fez um lançamento há apenas 2 meses; mas não se destina a PC desktop).
Após o lançamento da imagem ISO Redcore 2201, em Outubro 2022, o interesse ou curiosidade levou a distro de novo ao 1º lugar entre as “Gentoo-based” (105º lugar no geral), na média dos 6 meses até o início de Dezembro.
Fora dessas flutuações sazonais, o ranking reflete cliques induzidos por milhares de usuários, que estão sempre elogiando ou recomendando distros em centenas de fóruns e blogs mais populares, no mundo inteiro — e o Redcore Linux tem se mantido nessa faixa de variação (sempre considerando a média dos 6 meses anteriores). — Por experiência pessoal de mais de 15 anos, tenho verificado que esse ranking acaba por refletir um "mix balanceado" das distros "mais faladas", com repositórios mais completos, maior número de usuários para ajudarem uns aos outros, fóruns mais ativos ou maior presença em outros fóruns, conserto mais rápido de eventuais bugs etc.
Neste momento (Junho 2022), as outras distros que mantenho instaladas estão em 1º, 4º, 7º, 8º, 11º, 14º, 15º, 17º, 32º, 39º e 51º lugares, e a meu ver isso corresponde mais ou menos às gradações daquele "mix" — nada muito difícil (ok, Gentoo está em 50º, mas exige muita compilação). — Tentar uma distro que oscila na faixa do 83º ao 107º lugar implica em estar disposto a enfrentar um pouco mais de dificuldade, em pelo menos alguns quesitos daquele "mix balanceado".
Mas esse ranking foi só 1 dos elementos que levei em consideração. — Eu já tinha pesquisado as demais distros do ramo Gentoo (além dele próprio), para avaliar qual poderia se adequar melhor ao meu projeto, e achei que Redcore era a que me atenderia. — Conversando com os colegas, recebi a indicação de um vídeo do Terminal Root, que confirmou minha avaliação.
Os colegas também indicaram o Funtoo, que me pareceu mais complicado para começar — e o Bentoo, que visa ser um Funtoo mais amigável, mas ainda está em desenvolvimento. — Outra opção seria o Calculate Linux, que estava logo após o Redcore, e eu provavelmente tentaria caso este não me atendesse.
Enfim, o Redcore Linux oferecia imagem ISO já com KDE Plasma — a única, por sinal, o que indicava ter seu foco neste ambiente, que é a minha preferência.
 |
| Download da ISO do Redcore Linux 2101 pelo wget |
Naquela época, baixei a ISO Redcore Linux Hardened 2101 (=2021 nº 1), recém-lançada, verifiquei md5sum, sha256sum, "queimei" em DVD (para guardar) — mas não consegui completar o boot da sessão Live, por mais que tentasse. — Tive de resolver outras coisas mais urgentes, e acabei esquecendo do “ramo Gentoo”.
Só voltei àquele projeto no final do mês passado. Pesquisei mais um pouco, baixei e instalei o MocaccinoOS (muito fácil: nenhum problema) — mas depois não consegui atualizar, nem instalar nenhum pacote (erros do Luet ao acessar os repositórios, 2 dias seguidos; e quase sem resultados no Google), e concluí que não estou pronto para essa distro, ou ela ainda não está pronta para um "usuário comum" (mesmo que enxerido), como eu. — De fato, sua própria documentação (fraquíssima) alerta que continua "em andamento" (work in progress); e permanece até hoje na lista de espera do Distrowatch, desde Novembro 2020.
Infelizmente, minhas anotações e capturas de tela dos problemas com o Luet e seus repositórios estavam na pasta /home dele — que deletei sem pensar, depois de instalar o Redcore.
Enfim, baixei a ISO Redcore Linux Hardened 2102 (=2021 nº 2), lançada em Outubro 2021, verifiquei md5sum, sha256sum, "queimei" em DVD — o boot da sessão Live concluiu de imediato — e instalei com a maior facilidade, sem nenhum problema.
Após 6 meses de uso, continua atendendo ao meu objetivo de: — (1) Ser fácil para começar; e (2) Ser uma “porta de entrada” para me familiarizar, sem pressa, com o universo do Gentoo.
__________________________
Publicado inicialmente em 14 Junho 2022. — Atualizado até Dezembro 2022.
— … ≠ • ≠ … —
PC desktop UEFI / GPT
- Transição para hardware UEFI-GPT
- Arch Linux - install, config
- Debian testing - install, config
- Linux Mint 20 (beta) "Ulyana" + Plasma KDE
- Upgrade para o Fedora 32
- Void + KDE
- MX Linux 19.2 KDE Beta 2
- KDE Neon upgrade 20.04 Focal Fossa
- Slackware by Alien BOB
- Adicionando HDD a 11 distros Linux em dualboot
- Slackware 15 alpha1
- Manjaro - instalação e configuração
- PCLinuxOS KDE Darkstar - instalação de substituição
- MX Linux 21 Wildflower KDE - instalação de substituição
- Linux, dualboot, discos, partições e backups
- Redcore Linux - instalação e configuração
Nenhum comentário:
Postar um comentário