Descobrindo o Redcore Linux

Instalei o Redcore Linux para continuar me familiarizando com o “mundo Gentoo” de maneira gradual, segura e lenta.

O download da imagem ISO Redcore Linux Hardened 2102 (=2021 nº 2 ), lançada em Outubro 2021, foi um tanto incomum. Clicar nos links não inicia download nenhum, no meu navegador. No ano passado, acabei copiando os links e baixei pelo wget. Agora, usei o menu de contexto “salvar link como”, que baixa tudo mas não termina. O navegador avisa que não pode baixar com segurança. Tive de clicar em “Manter” (Keep), e ainda tive de confirmar. Então, o navegador concluiu os downloads (salvou em disco). Verifiquei as somas md5 e sha256, estava tudo certo. – O espelho usado foi o de Princeton e a velocidade chegou até 22 MiB/s, bem perto do limite de 26,1 MiB/s da minha conexão de “200 megas”. – Ótimo, pois é terrível tentar usar distros que só têm espelhos na Europa ou na Rússia, já que só temos ligação direta com os EUA.

A instalação (pelo Calamares) foi muito simples e fácil, e a etapa final de implantação (slide show) demorou menos do que eu esperava, diante de tudo que li: – 20 minutos, de DVD para SSD (ambos em Sata3).

A atualização inicial, sim, foi coisa demorada. – Ignorei o Plasma Discover, pois nos últimos anos decidi usar apenas comandos (exceto nas distros que têm Synaptic :wink:). – O comando sisyphus, no caso do Redcore.

Após 8 meses do lançamento da ISO, já se acumularam 984 atualizações – e na primeira tentativa aconteceu uma falha e abortou após baixar 633, em 1 hora 19 minutos.

Tentei de novo imediatamente, sem pensar – depois tentei CTRL+C, mas não interrompeu, o que foi ótimo, pois dessa vez foi até o final, sem nenhum problema.

Não deu nenhum desconto, pelos 633 pacotes baixados antes – pois são instalados de imediato, e por isso entendo que não poderiam ser mantidos. – Baixou e instalou 984 pacotes “binários” em 3 horas 51 minutos, e no final deixou 420 linhas de mensagens para ler.

# sisyphus mirror list
# date; sisyphus spmsync; date
# date; sisyphus update; date
# date; sisyphus upgrade; date

A demora não foi causada por qualquer problema de conexão, pois os pacotes maiores foram baixados em até 20 MiB/s (Princeton foi mantido como espelho). – O caso é que são baixados, um por um, em seguida interrompe-se o download para instalação imediata, depois baixa outro pacote – e assim por diante.

E apesar de falar em pacotes “binários”, houve, sim, alguma compilação – com mais algum download adicional.

A procura e a instalação de pacotes pelos comandos sisyphus search e sisyphus install às vezes não encontra o que queremos, mas indica a existência de ebuilds do Gentoo que podem ser instalados com alguma compilação. – Por isso, o melhor é usar sempre sisyphus search PACKAGE --ebuild e sisyphus install PACKAGE --ebuild – pois se não for necessária compilação irá escolher automaticamente os pacotes binários.

Acho que instalei primeiro os pacotes mais “fáceis”, pois só 8 dias mais tarde me assustei com temperaturas de 100ºC ao instalar o Foliate e, principalmente, ao instalar o KStars. – A compilação de algumas dependências deste último produziu longos momentos de 100ºC – mas notei que em nenhum momento passou, sequer 1 grau, desse limiar crítico. Examinando em retrospecto, vejo que, quando a temperatura se eleva demais, o “Turbo” automaticamente reduz a frequência, do máximo de 4,1 GHz para alguma coisa em torno de 3,7 GHz. Acho que, se precisasse, reduziria o clock ainda mais.

Googlei “temperature compiling gentoo”, li 3 ou 4 debates no fórum Gentoo, e me convenci de que a mera limpeza da ventoinha e troca da pasta térmica não reduziria as temperaturas de 100ºC para menos de 60ºC, que muitos lá diziam ser o máximo observado. – Um exame das fotos e capturas de tela desde a montagem do computador, em Janeiro 2020, mostrou que nesses 2 anos e meio as temperaturas aqui aumentaram, no máximo, 11ºC, e provavelmente apenas a metade disso. Então, sim, está na hora de manutenção na máquina, mas não era aí que estava o maior problema.

Alguma coisa que vi comentarem no fórum Gentoo me levou a desabilitar o “Intel Turbo Booster” no UEFI Bios Setup da placa-mãe, para ver o resultado. – Removi o Foliate, removi os pacotes órfãos, e tornei a instalar o Foliate.

Dessa vez, as temperaturas já começaram um pouco mais baixas logo após o boot (detalhe no alto, acima) – e durante a reinstalação do Foliate ficaram na faixa de 60ºC a 70ºC (detalhe ao centro, acima). – Agora, sim, a limpeza do cooler será capaz de trazer essas temperaturas para a faixa de 50ºC a 60ºC.

O “Intel Turbo Booster” costuma ser ativado por padrão, pelas placas-mãe compatíveis – e como não jogo nem tenho o hábito de fazer processamentos intensivos, nunca pensei no assunto, nem nunca li sobre isso. – Agora, já baixei mais umas páginas da Intel sobre o i5-9400, Turbo Booster etc., e quando o assunto aparecer na minha frente já vou entender do que se trata. :disguised_face:

Pelo que notei nos últimos meses, nas outras distros a frequência varia rapidamente de 0,8 GHz até 4,1 GHz, quando necessário, mas voltam rapidamente ao mínimo, quando vou buscar um café – mesmo que haja 10 aplicativos abertos (porém sem atividade). – Exceção era o Slackware, que já começa em 3,9 GHz e assim permanece o tempo todo. E o Redcore também, até que desabilitei o Turbo.

Sem o Turbo, o Redcore começa com 2,9 GHz e assim se mantém – a menos, talvez, que eu consiga encontrar uma mega-compilação, quem sabe.

Fiz um relato dessa experiência – e provavelmente vou acrescentar mais algumas descobertas, nas próximas semanas e meses:

8 curtidas

o “problema” do download deve-se a mecanismo de segurança do navegador.

1 curtida

Faz todo sentido.

Só estranhei, porque nas outras distros basta clicar para iniciar o download, e o navegador aceita sem problema.

Sobre a demora ao começar o download de um pacote:
No OpenSuse algum tempo atrás eu sofri com isso durante a instalação. O problema é que um algoritmo mais esperto vai buscando novos arquivos enquanto a instalação do pacote atual acontece. No gentoo tem uma flag pra ativar esse download em fundo (no make.conf FEATURES="parallel-fetch parallel-install"). Mas também no gentoo não faz tanta diferença porque vc vai ter que compilar o pacote e vai demorar muito mais do que o download do pacote. Talvez tenha alguma opção parecida no Redcore que venha desativada por padrão.

Sobre temperaturas de compilação:
Realmente o processo de compilação é um dos mais extremos tanto para o processador quanto para a memória. Eu comecei a ficar paranóico em busca dos 70 graus no ryzen 3 para boost total, e percebi que o valor de propaganda de bost máximo é teórico… Daí já desencanei e só me preocupo se bater acima de 90, uma vez que o próprio processador já se ajusta a temperatura de trabalho e não “gasta mais rápido” se estiver mais quente.

2 curtidas

Encontrei um motivo para começar a ler sobre flags, use etc.

O Dolphin do Redcore Linux veio “capado” desses quesitos:

  1. Painel “Informações” (F11)

  2. Opção de “Mostrar dicas”

  3. Mostrar dados Exif das fotos

  4. Etc.

Nos primeiros 2 quesitos, uma pesquisa rápida por “dolphin gentoo panel” indicou, logo no primeiro link do Google, que eu precisaria ativar a flag “semantic-desktop” e recompilar.

Acima - Editei um arquivo que diz expressamente “Não edite”, em seguida usei um comando emerge para incluir a flag alterada.

E, pronto – agora tenho a opção do painel “Informações”:

De quebra, também apareceu a opção de “Mostrar dicas”:

Só não encontrei (ainda) um jeito de exibir os dados Exif das fotos no Dolphin – embora o Gwenview faça isso.

“Basta” exibir o painel lateral (F4) do Gwenview e clicar em “Mais informações”:

Agora, ler sobre as flags, use etc. – para aprender a maneira correta de fazer essas coisas.

1 curtida

Redcore 2201

640x414
Imagem: 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 exatas 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 em sua totalidade.

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, não percebi 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 as coisas para os mantenedores da distro. (Sim, já vi isso em outras distros).

640x360
Imagem: 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 cabíveis.