 |
| Mageia Cauldron identifica-se como “Mageia 9”, no momento • |
Cauldron é a versão de desenvolvimento do Mageia — onde se prepara o próximo lançamento — depois, o lançamento seguinte — e assim por diante.
Comporta-se como um lançamento contínuo (rolling release) — mas não é feito para isso, nem se recomenda para uso comum. — É para desenvolvedores e testadores.
- Mageia adverte que o “Cauldron pode quebrar seu computador, devorar seus dados, incendiar sua casa ou matar seus gatinhos”. — Se você precisa de uma distro “confiável” para o seu trabalho, fique sempre com a versão “estável”.
Em suma: é a versão de teste. — É como instalar Mageia 9 beta2, para ver o desenvolvimento final da próxima versão — e não parar mais de acompanhar os desenvolvimentos posteriores... Mageia 10... Mageia 11... etc.
Em vez de instalar, optei por fazer upgrade do meu Mageia 8 (stable) para Cauldron (testing) — de modo a preservar, na medida do possível, os pacotes que adicionei nos últimos 2 anos, as configurações em /etc e tudo mais.
- Isto não é um “tutorial”! — É só um registro para lembrar o que fiz, e como fiz — inclusive, erros... e desobediência às recomendações oficiais.
Índice
- Roteiro
- Bem-vindo ao Mageia Cauldron
- Ajuste fino
- Escovando bits
- Conclusões
- Por que Cauldron?
- E por que não via DNF?
Roteiro
 |
| Atualização do Mageia 8, antes de iniciar o upgrade para Cauldron |
Leia as recomendações oficiais com atenção.
Basicamente — pelo urpmi:
- Atualizar o Mageia estável
- Remover os Repositórios da versão estável
- Adicionar os Repositórios do Cauldron
- Testar o upgrade (download e simulação)
- Fazer o upgrade
Por distração, pulei o teste — e fiz logo o upgrade — o que é um perigo!
Em negrito, no histórico do bash — que não registrou a atualização inicial (imagem acima: 11:35):
# history
776 2023-07-04_11-42-32 # dnf --version
...
784 2023-07-04_12-25-49 # rpm -qa | sort > packages-installed-Mageia8.txt
...
786 2023-07-04_13-01-43 # urpmi.removemedia -a
788 2023-07-04_13-02-51 # urpmi.addmedia --distrib 'http://mageia.c3sl.ufpr.br/distrib/cauldron/x86_64/'
790 2023-07-04_13-06-21 # systemctl stop dnf-makecache.service
791 2023-07-04_13-06-41 # systemctl stop dnf-makecache.timer && systemctl daemon-reload
792 2023-07-04_13-11-02 # date; urpmi --auto-update --auto --force; date
793 2023-07-04_13-10-03 # script upgrade_log-1.txt
...
797 2023-07-04_13-44-26 # rpm -qa | sort > packages-installed-Mageia9-Cauldron.txt
799 2023-07-04_13-49-40 # urpmi --clean
Acima: - Depois do urpmi --auto-update, verifiquei se o dnf estava instalado (estava) — pois neste caso podia ser bom parar o dnf-makecache pelo systemctl. — Isso era uma recomendação antiga (de que dnf-makecache podia travar o upgrade via urpmi), mas não sei se ainda é necessária.
Pelo comando rpm, salvei uma lista dos pacotes instalados no Mageia 8.
Removi os repositórios do Mageia 8 pelo comando urpmi.removemedia -a.
 |
| Comando urpmi.addmedia para Cauldron x86_64 de um espelho específico |
Adaptei o comando urpmi.addmedia para adicionar Cauldron e a arquitetura x86_64 — de um espelho específico.
- Mecanismos de escolha automática de espelhos mais “próximos”, ou “mais responsivos”, são muito úteis para quem começa a usar distros Linux, ou não quer gastar tempo e neurônios — mas “o melhor da hora”, nem sempre é o melhor a médio e longo prazo. — Já usei dúzias de espelhos do Brasil e do exterior, e sei em quais posso confiar, levando em conta também as conexões até a minha cidade.
Parei o serviço dnf-makecache — e iniciei o Typescript, para registrar todas as mensagens do upgrade. — O histórico só registra o comando Typescript no final da gravação, ou seja, após o comando de upgrade (embora com o horário anterior).
Pelo comando rpm, salvei uma nova lista dos pacotes instalados — agora, no “Mageia 9” Cauldron — e limpei o cache de pacotes baixados pelo urpmi.
 |
| Dolphin parou de funcionar no meio do upgrade para Cauldron |
Recomenda-se não fazer o upgrade do Mageia dentro de uma sessão desktop, mas é claro que não obedeci. — Perto do final, o Dolphin não conseguia mais abrir outras pastas — mas o Kate e o gnome-screenshot continuaram gravando seus arquivos normalmente, e pude documentar o processo todo, sem lacunas.
 |
| urpmi alterna download e instalação (e remoção!), por grupos de pacotes |
O upgrade, propriamente dito, se realizou em 11 minutos (13:11 às 13:22), com uma conexão de 480 “megas” (480 Mbit/s = 57,22 MiB/s), alternando download, instalação (e remoção!) de grupos de pacotes.
Script started on 2023-07-04 13:10:03-03:00
# date; urpmi --auto-update --auto --force; date
Tue 4 Jul 13:11:02 -03 2023
(...)
You should restart your computer for dbus, glibc, kernel-desktop, systemd
Tue 4 Jul 13:21:51 -03 2023
exit
Script done on 2023-07-04 13:22:18-03:00
 |
| Download, instalação e remoção de grupos de pacotes pelo urpmi |
Ao contrário do upgrade pelo dnf — que baixa todos os pacotes de uma vez, e depois reinicia o PC para aplicar as alterações fora do ambiente desktop — o urpmi baixa e instala um grupo de pacotes de cada vez, ao mesmo tempo em que já vai removendo os grupos de pacotes substituídos.
Isso é um perigo — caso haja qualquer falha ou interrupção no meio do processo!
Por isso, é recomendado fazer o download de todos os pacotes, seguido de um teste que apenas simula o upgrade, para detectar possíveis falhas — antes de realmente fazer o upgrade — mas por distração, não notei que eu tinha esquecido de adicionar esses 2 parâmetros ao comando:
# urpmi --auto-update --auto --download-all --test
Felizmente, a energia elétrica não caiu durante o processo — e não houve falha no download de nenhum pacote.
Foi por decisão consciente que — contra todas as recomendações — decidi fazer o upgrade dentro da sessão KDE Plasma, e com vários aplicativos abertos.
Mas as falhas e erros devem-se ao fato de que li coisas demais: — instruções de upgrade para Cauldron, instruções de upgrade do Mageia 7 para Mageia 8, instruções de upgrade pelo urpmi e pelo dnf — e fiz uma bela confusão com esse excesso de leituras, sem parar para resumir um roteiro simples e claro, e conferir com atenção, antes de começar.
- Para instalar o Arch pela primeira vez, li 300 vezes mais — mas tive o cuidado de resumir um roteiro simples e claro. — Agora, resolvi fazer o upgrade, e agi de improviso, o que não é recomendável.
Por isso, registro aqui apenas o que fiz — não um “roteiro ideal” — e evito falar de outros métodos de upgrade (para não confundir, e porque não testei).
Bem-vindo ao Mageia Cauldron
 |
| Grub do Mageia Cauldron consegue detectar e carregar openSUSE em BtrFS |
Ao reiniciar o computador, o Grub do Mageia Cauldron tinha assumido a prioridade de boot no UEFI Bios.
A sessão KDE exibiu o Painel aos 20 segundos uptime (Auto Login). — A média das 6 inicializações seguintes foi de 17 segundos até exibir o Painel. — Ver “Conclusões”, adiante.
Eu ainda não tinha re-configurado os repositórios do Google — mas o Chrome e o GoogleEarth não foram removidos.
O MSEC tinha voltado à configuração padrão — “Enable periodic security checks”, que desativei outra vez — mas manteve o acesso que eu tinha concedido ao KDE Connect.
 |
| Atualização do Grub do openSUSE, meu Menu de inicialização |
O Grub do Mageia Cauldron continua capaz de detectar o openSUSE, instalado em sistema de arquivos BtrFS, sem partição de /boot separada. — Devolvi a prioridade de boot ao openSUSE pelo efibootmgr — e atualizei seu Grub para detectar o novo Mageia Cauldron.
 |
| KDE-PIM a todo vapor, com 17+ processos Akonadi y otras cositas más |
Aos 10 minutos (iddle) da 2ª sessão do Mageia Cauldron KDE, o uso de Memória RAM ficou em 1.384 MiB — 30% acima do uso no Mageia 8.
Isso me alertou de que o KDE-PIM estava em plena atividade, com 17+ processos Akonadi — entre outras coisas, que eu tinha desativado / removido do Mageia 8.
Isso também deu uma pista para o motivo de o número de pacotes instalados ter aumentado em 323 — de 2.696 no Mageia 8 para 3.019 no Mageia Cauldron.
- A causa talvez seja porque fiz upgrade com o parâmetro --force, ausente nas recomendações oficiais: — “force invocation even if some packages do not exist”. — Como não se podem invocar pacotes inexistentes, suponho que queira dizer “pacotes não-instalados”.
 |
| Remoção de dezenas de pacotes do KDE-PIM, pelo rpmDrake |
Pelo rpmDrake, pesquisei PIM, Kmail, KAddressbook, Kontact, KOrganizer, KNotes, KAlarm, Akonadi etc., e removi quase tudo — com toneladas de dependências — poupando só o que ameaçasse remover pacotes úteis, ou quebrar o ambiente KDE.
Importante: - Preservo sempre o baloo e o baloo-widgets (+2 bibliotecas), que são indispensáveis ao ambiente Plasma KDE.
Removi também o dnf, que não pretendo usar.
Enfim, executei o urpme --auto-orphans para eliminar o que sobrou.
Com isso, o número de pacotes instalados recuou para 2.862 — o que ainda é 166 a mais do que eu tinha no Mageia 8 — e nos 2 boots seguintes, o uso de Memória RAM aos 10 minutos (iddle) recuou para 1015 MiB e 1.004 MiB, o que está mais próximo dos 1.068 MiB do Mageia 8 no mês anterior.
- Variações de até 40 MiB ocorrem a cada segundo — por isso, não vale a pena levar muito a sério pequenas diferenças no “uso inicial de Memória RAM” entre 2 distros — e se você tem mais de 4 GB RAM, não perca tempo com isso. Use a distro e o DE que quiser, e seja feliz!
 |
| Desabilitando alguns serviços do Plasma Search |
Essa redução de uso de Memória RAM também se deveu, em parte, à desativação de vários Background Services, Desktop Effects e serviços do Plasma Search que eu não utilizo — mas que tinham sido reativados no upgrade para Cauldron.
 |
| Substituição do widget Weather pelo Weather2 |
Substituí o velho widget Weather — que ainda funcionava com a versão antiga do KDE Plasma — pelo Weather2.
 |
| Dynamic Word Wrap e Show Line Numbers no KWrite |
As versões mais recentes do KWrite (e do Kate) perderam os atalhos para alternar (on / off) Dynamic Word Wrap (F10) e Show Line Numbers (F11). — F10 pode ser configurado manualmente — ao passo que F11 agora conflita com o atalho global, mas bastou configurar para sempre exibir a numeração das linhas.
 |
| speedtest-cli e corona-cli funcionam normalmente |
O speedtest-cli funciona normal (com as limitações by Ookla).
O corona-cli só precisou ser atualizado (por comando npm), pois há tempos eu não fazia isso.
Tue 1 Nov 13:43:02 -03 2022 Tue 4 Jul 16:50:51 -03 2023
medium "Core Release (distrib1)" is up-to-date medium "Core Release" is up-to-date
medium "Core Updates (distrib3)" is up-to-date medium "Core Updates" is up-to-date
medium "Nonfree Release (distrib11)" is up-to-date medium "Nonfree Release" is up-to-date
medium "Nonfree Updates (distrib13)" is up-to-date medium "Nonfree Updates" is up-to-date
medium "Tainted Release (distrib21)" is up-to-date medium "Tainted Release" is up-to-date
medium "Tainted Updates (distrib23)" is up-to-date medium "Tainted Updates" is up-to-date
medium "Core 32bit Release (distrib31)" is up-to-date medium "Core 32bit Release" is up-to-date
medium "Core 32bit Updates (distrib32)" is up-to-date medium "Core 32bit Updates" is up-to-date
medium "Nonfree 32bit Release (distrib36)" is up-to-date medium "Nonfree 32bit Release" is up-to-date
medium "Nonfree 32bit Updates (distrib37)" is up-to-date medium "Nonfree 32bit Updates" is up-to-date
medium "Tainted 32bit Release (distrib41)" is up-to-date medium "Tainted 32bit Release" is up-to-date
medium "Tainted 32bit Updates (distrib42)" is up-to-date medium "Tainted 32bit Updates" is up-to-date
medium "earth_x86_64" is up-to-date
medium "chrome_x86_64" is up-to-date
2023-07-05 12:07:53
# urpmi.addmedia --update chrome_x86_64 http://dl.google.com/linux/chrome/rpm/stable/x86_64
adding medium "chrome_x86_64"
http://dl.google.com/linux/chrome/rpm/stable/x86_64/media_info/synthesis.hdlist.cz
# rpm --import https://dl-ssl.google.com/linux/linux_signing_key.pub
# urpmi.addmedia --update earth_x86_64 http://dl.google.com/linux/earth/rpm/stable/x86_64
adding medium "earth_x86_64"
http://dl.google.com/linux/earth/rpm/stable/x86_64/media_info/synthesis.hdlist.cz
Acima: - Os “canais” (medium; media; distrib) do Mageia Cauldron, adicionados pelo urpmi.addmedia, são os mesmos que eu tinha no Mageia 8.
Só alguns desses “canais” vieram habilitados, ao instalar o Mageia 8 (distrib1, 3, 11, 13, 36, 37, se não me engano); e os outros, habilitei depois. — Isto sugere que, ao “remover todos”, essa configuração foi preservada; e ao usar o comando urpmi.addmedia para escolher “Cauldron”, ele já sabia quais “canais” deviam ser habilitados.
Só precisei adicionar os repositórios do Google e obter sua chave pública.
- No caso do GoogleEarth, mais tarde substituí “http” por “https”, só para seguir a versão atual da Wiki — mas isso não trouxe nenhuma atualização do pacote — e a busca por cidades, ruas etc. continua sem funcionar (como já não funcionava no Mageia 8).
Tudo mais — o KDE Plasma, os Aplicativos KDE e demais aplicativos que eu já tinha no Mageia 8 — continua funcionando no Mageia Cauldron.
No Gimp, mantiveram-se inúmeras configurações — mas outras, tive de refazer, tal como já havia acontecido, por exemplo, na transição para o Gimp 2.10.
É possível que eu encontre mais alguma coisa, em outros aplicativos, que ainda não abri até o momento. — Faz parte da vida.
 |
| Falha em “Abrir com Gimp”, no Menu de contexto do Gwenview |
O único problema novo (falta solucionar!), é que no Menu de contexto do Gwenview, ao clicar em “Abrir com Gimp”, abre uma nova instância do Gwenview. — Isso é chato, pois uso muito, no dia-a-dia. — Mas no Dolphin, o Menu de contexto “Abrir com Gimp” funciona sem qualquer problema.
O yt-dlp está encontrando muitos “erros”, embora a versão seja de Junho 2023 — mas não tenho usado outras distros, para comparar. — Talvez o Youtube tenha colocado novas barreiras, a serem dribladas pela próxima versão do pacote.
Ajuste fino
 |
| “MyPlaces” importado do Arch Linux |
No GoogleEarth, importei os “Meus Lugares” do Arch Linux, movi seu conteúdo para os “Meus Lugares” do Mageia, reorganizei e salvei. — Depois salvei uma cópia na minha partição de documentos (Warehouse, com backups semanais).
 |
| Icons-only Taskbar, mais discreto |
Agora que estou no Mageia Cauldron por um longo período, troquei o Taskmanager (Gerenciador de tarefas) pelo “Icons-only Taskmanager” — que é mais discreto e facilita trabalhar com muitas janelas — em ordem “manual” (Sort: Manually) e sem agrupar (Do not group).
 |
| Ocupação da pasta ~/.cache |
Meia hora antes do upgrade, no dia 4 Julho, a ocupação da partição /home estava em 6,47 GiB — mas no dia 10 (menos de uma semana depois!). já tinha chegado a 11,6 GiB — um aumento vertiginoso, que nunca vi em nenhuma distro.
Pelo Filelight, verifiquei que havia 4,3 GiB em ~/.cache/tracker3; e mais 1,5 GiB em ~/.cache/thumbnails. — Costumo deletar manualmente os Thumbnails, que proliferam (e se acumulam para sempre), quando vejo alguma partição /home chegar perto da lotação máxima; — mas nunca vi nem ouvi falar de tracker.
Numa pesquisa rápida, vi que é um indexador do Gnome — equivalente, talvez, ao baloo_file do KDE (que removo sempre que encontro). — Segundo meus registros, o tracker e o tracker-miners foram instalados como dependências do Foliate, em Setembro 2020 (mas ficaram quietos, até a semana passada).
Tentei remover o tracker, mas o urpme avisou que isso removeria 147 pacotes — incluindo Gimp, Chrome, LibreOffice, lsb, mate-polkit (?), plasma-desktop, rpmdrake, Xsane — a maioria dos quais, já estavam instalados, antes do tracker, e por isso é difícil acreditar que não possam viver sem ele.
Mas consegui remover o tracker-miners — e aproveitei para remover o gnome-desktop e o Firefox, que não uso. — Depois disso, não apareceram novos arquivos na pasta ~/.cache/tracker3 (que esvaziei).
Esvaziar a pasta ~/.cache/thumbnails foi mais complicado, pois eram tantos, que o rm pediu arrego — mas o comando find conseguiu. — E restavam muitas outras subpastas em ~/.cache, que eu não iria deletar em massa, sem pesquisar o que são, e as possíveis consequências.
Acabei ficando com um meio-termo: — Deletar tudo que não é acessado há mais de 1 ano — e criei um agendamento para fazer isso 15 minutos após o boot (para não interferir no registro do uso de RAM, aos 10 minutos):
$ crontab -l
@reboot echo ' ' > done.txt
@reboot sleep 600; bash RAM.sh
@reboot sleep 780; bash VERSIONS.sh
@reboot sleep 900; find ~/.cache/ -type f -atime +365 -delete
Depois dessas manobras, a ocupação da pasta /home caiu para 4,12 GiB — e, o que é mais importante: — parou de aumentar naquele ritmo alucinado.
Resolvi mover meus scripts para ~/bin — e eles continuaram funcionando pelo Conky e por comandos manuais, pois a pasta já estava no $PATH — mas o cron não os encontrou mais.
Em geral, o PATH do ambiente cron é /usr/bin:/bin, e por motivos de segurança, ele não lê o perfil de usuário (.bash_rc, .bash_profile). — Pode-se redefinir o PATH no início do crontab, mas para evitar um longo estudo (e possíveis erros), achei mais simples apenas indicar o “caminho” dos scripts:
$ crontab -l
@reboot echo ' ' > done.txt
@reboot sleep 600; bash /home/flavio/bin/RAM.sh
@reboot sleep 780; bash /home/flavio/bin/VERSIONS.sh
@reboot sleep 900; find ~/.cache/ -type f -atime +365 -delete
Escovando bits
Não consegui remover Flatpak. — O comando urpme avisa que isso implica em remover partes do KDE. — Segundo meus registros, Flatpak foi instalado por uma simples atualização do sistema, em Julho 2020.
Também não pude remover PackageKit. — O comando urpme diz que isso implica em remover Dolphin e outras coisas essenciais. — Isso parece loucura, e desconfio, cada vez mais, que se deva a alguma configuração exagerada, de considerar pacotes “sugeridos” como se fossem “dependências” cruciais (como no openSUSE).
Fiquei alarmado ao perceber que, às vezes, urpme desinstala pacotes sem pedir confirmação — e ainda não sei, em quais casos — o que torna essa brincadeira um tanto perigosa, até que eu aprenda mais.
Um caso típico são os metapacotes “task” — como o task-plasma5, que deixou órfãos ksystemstats e plasma-systemmonitor.
Para não perder a comodidade do comando urpme --auto-orphans, tive de marcá-los como “instalados explicitamente”. — Para isso, basta tentar reinstalá-los, pois nesse caso o urpmi limita-se a retirá-los da lista de pacotes órfãos. — Este comando facilita a tarefa:
# date; urpmi $(urpmq --auto-orphans -f); date
Thu 13 Jul 14:23:53 -03 2023
Packages kernel-desktop-6.3.9-2.mga9.x86_64, ksystemstats-5.27.5-1.mga9.x86_64, plasma-systemmonitor-5.27.5-1.mga9.x86_64 are already installed
Marking kernel-desktop as manually installed, it won't be auto-orphaned
Marking ksystemstats as manually installed, it won't be auto-orphaned
Marking plasma-systemmonitor as manually installed, it won't be auto-orphaned
writing /var/lib/rpm/installed-through-deps.list
Thu 13 Jul 14:23:55 -03 2023
Infelizmente, isso também foi aplicado ao Kernel 6.3.9-2 — que agora não será mais eliminado automaticamente, na hora devida. — Vou ter de removê-lo, eu mesmo, quando não for mais necessário.
 |
| Verificando pelo rpmDrake os meta-pacotes instalados |
Um exame pelo rpmDrake, filtrando “Meta packages”, mostrou que ficaram apenas task-pulseaudio, basesystem, task-obsolete, task-x11 e task-codec-video — nos quais prefiro não mexer, por enquanto.
Importante: - O usuário do Mageia não precisa perder tempo com esse tipo de minúcias, pois o sistema é feito para ser amigável e sólido. — Faço essas coisas só para explorar as entranhas da distro e entender seus mecanismos internos, como um guri que desmonta os brinquedos. — Com 16 GB RAM e uma partição de 30 GiB, não há necessidade de “economizar bits”.
 |
| Opção “Imprimir para um arquivo”, no LibreOffice Calc |
Eu já tinha removido hplip desde Outubro 2020 — e agora removi o que havia sobrado do cups — um teste que eu queria fazer há muito tempo, pois me desfiz de minha última impressora há mais de 20 anos.
Após reiniciar, o Chrome continua imprimindo em PDF (CTRL+P) — e no LibreOffice ainda funciona o “Export as PDF” (que prefiro). — Para “imprimir” no LibreOffice, preciso selecionar manualmente “Print to file”, enquanto não descobrir como mudar o padrão “Generic printer”
Conclusões
 |
| Quadro 1 - Estado das minhas distros em 11 Junho 2023 |
Quadro 1 - A “usabilidade” do Mageia Cauldron, para mim, não se alterou, em relação ao Mageia 8 do mês passado, quando fiz a última verificação do “estado” das distros instaladas no meu PC. — Sinto um impulso de afirmar que, agora, o Mageia se tornou uma de minhas “distros preferidas” — mas a razão fria me garante que isso é entusiasmo com “brinquedo novo”.
 |
| Quadro 2 - Mageia Cauldron face às outras distros no mês passado |
Quadro 2 - Tudo no Mageia Cauldron está “mais atual” — e vai continuar “sempre atual”, pois Cauldron é sinônimo de “atualização permanente” — mas o grande “ganho” é que “não perdi nenhuma usabilidade” que eu tinha antes.
Isso não é pouca coisa. — Significa que todo novo aprendizado pode me levar para frente, em vez de perder tempo consertando retrocessos. — Com a diferença, de que uma distro “atual” me anima muito mais a investir no aprendizado e solução de problemas, do que uma distro “estagnada” durante 2 anos.
Boot times:
2023-07-04 18:38 Mg 18’’
2023-07-05 07:25 Mg 17’’
2023-07-06 10:26 Mg 17’’
2023-07-09 14:04 Mg 17’’
2023-07-10 14:48 Mg 17’’
2023-07-11 17:29 Mg 18’’ average 17’’
RAM usage 10 min uptime (iddle):
2 1015 MiB
3 1004 MiB
4 998 MiB
5 1011 MiB
6 1003 MiB
7 1007 MiB
8 1006 MiB average: 1006 MiB
Other SO's - just 1 sample, back in 11 June:
Void 878 MiB
PCLinuxOS 921 MiB
Slackware 15 940 MiB
MX Linux 21 940 MiB
Redcore 1,001 MiB
Mageia Cauldron 1,006 MiB
Manjaro 1,031 MiB
KDE Neon (Jammy) 1,049 MiB
Arch 1,059 MiB
Fedora 38 1,139 MiB
openSUSE Tumbleweed 1,210 MiB
Debian testing 1,211 MiB
A média de 17 segundos do boot até exibir o Painel do KDE não representa grande melhora em relação aos 18 segundos da média anterior — pois em Maio e Junho também houve 5 registros de 17 segundos — e apenas 2 casos puxaram a média um pouco para cima.
Quanto à redução do uso inicial de Memória RAM, pode ter sido causada por um ajuste mais rigoroso na desativação de serviços que não uso.
Enfim, mantive a data de instalação: Julho 2020 — porque, de fato, é a instalação que continuo usando — agora, como “Cauldron”.
Por que Cauldron
Fiz o upgrade do Mageia 8 (stable) para o Mageia Cauldron (testing) para me antecipar ao próximo lançamento do Mageia 9 — mas também para me livrar daquela rotina de instalar uma nova versão a cada 2 anos, com todo o trabalho de configurar repositórios, adicionar pacotes etc. — O upgrade preserva a maior parte do trabalho já realizado para adequar a distro ao que eu preciso.
Me acostumei às distros Linux de lançamento contínuo — 6½ anos com o Debian testing, 6 anos com o Arch, 5 anos com o PCLinuxOS, 4 anos com o openSUSE Tumbleweed e com o Void — e acabei perdendo o interesse por distros “estáveis”, ou de “lançamento fixo”, que ficam estagnadas durante 2 anos, e depois dão trabalho.
Nesse período, instalei o Mageia 6 sta2 (uns 4 meses antes do lançamento); o Mageia 7 beta2 (uns 3 meses antes do lançamento); e o Mageia 8 alpha1 (uns 6 meses antes do lançamento). — Portanto, lidei pelo menos 3 vezes com a fase final de desenvolvimento dessa distro; e nunca tive problemas com isso. — Havia muitas atualizações, pacotes sempre nas versões mais recentes. Quase um rolling-release! Mas após os lançamentos, as coisas estagnavam e perdiam a graça.
O que fiz agora foi evitar mais uma instalação — que neste momento, seria a do Mageia 9 beta2 — e várias outras, nos próximos anos.
E por que não via DNF?
 |
| Aviso para não misturar dnf e urpmi |
Já fiz 8 upgrades do Fedora pelo dnf — do 30 para o 31, para o Fedora 32 — e não parei mais, até o Fedora 38 (por enquanto), sem nenhum problema.
De início, até achei que poderia ser mais cômodo fazer o upgrade do Mageia pelo dnf — mas vi que não é bom alternar o uso dele com o do urpmi.
Há motivos para não misturá-los.
A Wiki do Mageia é clara: — “URPMI e DNF usam métodos diferentes para rastrear órfãos. Se você usar os dois, nunca deve usar a funcionalidade automática de nenhum deles para remover órfãos”.
Enfim, já uso o dnf no Fedora — e no Mageia prefiro continuar explorando o urpmi.
___________________
• Publicado em 5 Julho 2023 e desenvolvido até 7 Agosto 2023.
— … ≠ “•” ≠ … —
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
- Multiboot de 12 distros Linux
- Upgrade do Mageia 8 para o Cauldron (Mageia9)
- MX Linux 23 “Libretto” KDE - instalação e configuração
