Fedora 42 - by Jesse Smith (Distrowatch)

frc_kde · Abril 21, 2025, 7:57pm

Esta é uma “tradução Google” do artigo do Jesse Smith no Distrowatch – e deixo para comentar no final, ou no campo de Comentários. – Optei por não incluir as imagens (só as legendas!) – nem os links existentes no texto do artigo.

O projeto Fedora anunciou o lançamento do Fedora 42 na semana passada. O lançamento eleva a versão “spin” do KDE Plasma para “edição”, equiparando-a à versão Workstation do GNOME em termos de visibilidade e suporte. A nova versão do Fedora também apresenta a versão desktop COSMIC . O anúncio de lançamento do Fedora 42 traz outro recurso interessante:

Talvez o mais empolgante seja que temos uma nova interface de instalação! A interface anterior foi projetada para gerenciar muitas opções de configuração antes mesmo de você começar. Na última década, porém, passamos a “instalar o sistema completo sem complicações e, em seguida, configurar o que você precisa a partir de um ambiente completo”. Isso tornou o modelo “hub and spoke” mais confuso do que útil. A nova interface é simplificada e elegante.

Como o instalador do sistema tem sido um dos meus recursos favoritos nos lançamentos do Fedora na última década, eu estava ansioso para testar a nova abordagem. Antes de começarmos, o anúncio do lançamento trazia um aviso:

Descobrimos um problema com a mídia de inicialização Live no último minuto e, como a versão já estava fora do ar, não podemos fazer muito a respeito. Não causa nenhum dano, mas é irritante: a simples inicialização pela mídia Live adiciona uma entrada inesperada ao carregador de inicialização UEFI, mesmo quando o Fedora Linux 42 não está instalado no sistema local.

Lendo mais adiante, as notas de lançamento do Fedora compartilharam alguns novos itens para usuários de desktop: " O Fedora agora fornece o FEX, um emulador rápido que permite executar binários x86 e x86-64 em um host Linux AArch64. " Isso certamente pode ser útil para pessoas, especialmente gamers, que usam máquinas ARM de 64 bits. Outro novo recurso provavelmente também atrairá gamers: " Aplicativos que usam SDL 2 (tipicamente jogos) agora usarão SDL 3 de forma transparente por meio do pacote sdl2-compat. " Eu queria ver como a edição KDE Plasma se sairia, especialmente agora que era uma “edição oficial” em vez de uma entre muitas versões da comunidade. O download da edição KDE tinha 2,7 GB. A outra versão principal para desktop, chamada “Workstation” e que executa o GNOME, é um download de 2,3 GB.

Área de trabalho Live

: A opção de inicialização padrão da distribuição é testar a mídia live e, em seguida, iniciar o sistema operacional. Podemos, se desejarmos, pular o autoteste. Ambas as abordagens inicializam o Fedora e exibem a área de trabalho do Plasma, onde uma janela de boas-vindas é aberta. A primeira tela dessa janela de boas-vindas oferece a abertura do instalador do sistema do Fedora. Se pularmos esta etapa, as telas seguintes oferecem uma visão geral do Plasma com um pequeno tutorial sobre como usar a área de trabalho e o painel. Em seguida, vemos uma visão geral de alguns recursos importantes, como o KDE Connect, o painel de configurações e o Vaults. A próxima página da janela de boas-vindas oferece a abertura do centro de software Discover e a tela seguinte oferece a ativação de repositórios de software de terceiros. Depois de concluir todas essas etapas e fechar a janela de boas-vindas, ainda podemos acessar o instalador do sistema a partir de um ícone na área de trabalho. Este é o único ícone visível na área de trabalho do Plasma.

O Plasma é apresentado com um painel localizado na parte inferior da tela. Este painel apresenta, da esquerda para a direita: um menu de aplicativos, botões de inicialização rápida, um alternador de tarefas e a bandeja do sistema.

O Plasma ficou um pouco lento ao executar no ambiente de trabalho do meu laptop e anormalmente lento ao executar no VirtualBox. Pesquisei um pouco sobre isso e me deparei com uma situação complicada. Foi uma jornada de uma hora, e vou compartilhar apenas alguns dos destaques.

Havia dois problemas principais em jogo. Um deles era que a edição KDE do Fedora tinha uma quantidade anormalmente alta de RAM, usando mais de 3 GB para rodar apenas o desktop. Isso não era um grande problema no meu laptop, já que ele tem 8 GB de RAM, mas era um espaço apertado para a máquina virtual, já que o VirtualBox tinha 4 GB de RAM alocados para ela. Normalmente, isso é mais do que suficiente, já que um desktop e todos os meus aplicativos raramente usam mais de 2 GB a 3 GB de espaço, mas o Fedora consumia mais memória do que outras distribuições.

O segundo problema era que o Fedora usava um dispositivo de swap zRAM, que era armazenado na memória. A ideia era que a memória que não estava sendo usada pudesse ser compactada e mantida na memória, sendo descompactada quando necessário. Em teoria, isso gerava “mais” memória, pois os dados inativos eram compactados e o acesso ao espaço de swap falso era mais rápido, pois os dados ainda estavam na RAM em vez de no disco. No entanto, o que causou o colapso da situação foi que o Fedora estava usando tanta memória, mesmo quando ocioso, que tentava constantemente transferir os dados para a RAM compactada (o dispositivo virtual zRAM), mas quase tudo o que eu fazia exigia que os dados fossem trazidos de volta para a memória normal (descompactada).

A janela de boas-vindas
Fedora 42 – A janela de boas-vindas
(tamanho total da imagem: 1,2 MB, resolução: 1920x1080 pixels)

O resultado foi que centenas de megabytes de memória estavam sendo constantemente compactados e trocados, apenas para serem imediatamente descompactados e recarregados, e então compactados e trocados novamente. Minha CPU estava muito ocupada em ambos os ambientes, especialmente na máquina virtual. Decidi desabilitar o dispositivo zRAM e usar a RAM regularmente. Isso funcionou por um minuto, mas então a CPU começou a funcionar novamente. Verifiquei e descobri que o sistema havia recriado automaticamente o dispositivo zRAM e retomado a troca.

Uma pequena pesquisa revelou que esse é um problema conhecido e que as pessoas têm lutado contra a recriação automática da zRAM nos últimos cinco anos. Ele não pode ser desabilitado por métodos normais e requer um truque de linha de comando para fazer o systemd parar de reativar a zRAM. De qualquer forma, coloquei o hack do systemd em prática, desabilitei a zRAM e voltei a explorar o ambiente ao vivo. Isso tornou o sistema mais responsivo e as coisas estavam começando a melhorar, então voltei minha atenção para o instalador do sistema.

Instalando

Na primeira vez que tentei iniciar o instalador do sistema, a área de trabalho do Plasma travou. A entrada do teclado foi ignorada e acabei reiniciando o computador com força. Depois disso, em ambos os ambientes, o instalador foi iniciado e funcionou corretamente. No entanto, esta não foi a única falha de desktop que encontrei na semana passada.

Fiquei decepcionado ao descobrir que o instalador do sistema Anaconda não mudou. De fato, apesar dos comentários no anúncio de lançamento sobre a nova interface elegante, o Anaconda parece exatamente como tem sido na última década. Talvez haja uma maneira de iniciar um instalador diferente que eu não descobri lendo o anúncio e as notas de lançamento. De qualquer forma, me senti um pouco traído ao passar pela tela de opções usual do Fedora. Apesar da interface desajeitada, o Anaconda funcionou e foi bem tranquilo definir meu fuso horário, particionar o disco rígido, selecionar meu idioma e habilitar uma conexão de rede. Há também telas de configuração para definir a senha de root e criar uma conta de usuário comum.

A tela de particionamento de disco é um pouco complicada se usarmos a abordagem manual. Usar a opção automatizada configurará um volume Btrfs para nossos diretórios raiz e home. Assim como no ambiente live, o Swap é configurado como um dispositivo virtual zRAM em vez de um arquivo ou partição de swap.

O instalador copiou seus pacotes para o meu disco rígido, e o fez relativamente rápido. O processo de cópia levou cerca de cinco minutos e, em seguida, fui solicitado a reiniciar o computador.

Primeiras impressões

Após a instalação, o Fedora inicializou em uma tela gráfica de login. Ao acessar nossa conta, o desktop Plasma é aberto rodando o Wayland. (Por padrão, o Wayland é a única opção de sessão.) A janela de boas-vindas aparece na primeira vez que efetuamos login. Desta vez, a tela de boas-vindas para iniciar o instalador do sistema é substituída por uma configuração de telemetria, onde podemos escolher a quantidade de dados a serem enviados aos desenvolvedores do KDE. O padrão é não enviar dados.

O menu do aplicativo Plasma
Fedora 42 – Menu do aplicativo Plasma
(tamanho total da imagem: 1,2 MB, resolução: 1920x1080 pixels)

O Plasma usa um tema claro por padrão e a área de trabalho estava bastante silenciosa. Ao executar no meu laptop, a tela ficou estranhamente escura no início. Usar um atalho de teclado ou acessar o aplicativo Configurações do Sistema me permitiu ajustar a tela para um nível mais claro. O Fedora

de Hardware

conseguiu rodar em ambos os meus ambientes de teste e inicializou nos modos UEFI e BIOS Legacy. A distribuição funcionou razoavelmente bem no VirtualBox. A área de trabalho ficou um pouco lenta, mas era utilizável. Tive um desempenho melhor no meu laptop. O Plasma ofereceu uma resposta média e todo o hardware do meu laptop foi detectado. O áudio e a rede sem fio funcionaram, minhas teclas de mídia e brilho da tela funcionaram, e o touchpad registrou toques como cliques.

O anúncio de lançamento do projeto mencionou entradas extras aparecendo no carregador de inicialização UEFI e eu experimentei esse bug. É um pouco irritante, mas não é um problema prático.

O Fedora executando o Plasma consumia muitos recursos; é, de longe, a distribuição com maior consumo de RAM que já usei, ocupando 2,5 GB de memória. Para efeito de comparação, isso é cerca de 66% maior do que a segunda maior distribuição Linux que testei. Isso me fez pensar se eles deixaram a depuração ativada para alguns pacotes, já que isso parece surpreendentemente grande sem serviços ou recursos extras habilitados que compensariam o gigabyte extra de memória consumido. Em contraste, o Fedora usou apenas 4,3 GB de espaço em disco, o que é bem menor do que muitas outras distribuições Linux tradicionais. É cerca de metade do tamanho de muitas outras distribuições rodando GNOME ou Plasma que testei no ano passado.

O painel Configurações do sistema
Fedora 42 – Painel de configurações do sistema
(tamanho total da imagem: 888kB, resolução: 1920x1080 pixels)

Alguns leitores podem estar se perguntando se o dispositivo zRAM que mencionei anteriormente está contribuindo para esse grande consumo total de RAM. O total de 2,5 GB representa a quantidade de RAM normal consumida, independentemente de o dispositivo zRAM estar ativo ou ter sido desativado e removido. Usei o Fedora com e sem o dispositivo zRAM e o consumo de memória sempre ficou na faixa de 2,4 GB a 2,7 GB quando conectado ao Plasma sem nenhum aplicativo aberto. O valor de 2,5 GB geralmente era o valor em que o sistema se estabilizava quando a área de trabalho estava ociosa, em qualquer configuração.

Software incluído:

A edição KDE do Fedora vem com uma ampla gama de funcionalidades. Existem alguns aplicativos populares, como Firefox e LibreOffice. Também encontramos o software KDE Connect, o cliente de e-mail Kmail, um visualizador de área de trabalho remota e um cliente de bate-papo Matrix. O reprodutor de vídeo Dragon e o reprodutor de áudio Elisa estão incluídos e funcionaram para reproduzir meus arquivos de mídia. Há um leitor de código QR, uma agenda de endereços e um aplicativo de calendário/organizador. Também encontrei um visualizador de PDF, o gerenciador de arquivos Dolphin, um gerenciador de partições e um monitor de processos do sistema.

Para ajustar as configurações do desktop Plasma, o painel Configurações do Sistema está disponível e oferece bastante flexibilidade. Ao trabalhar na linha de comando, podemos encontrar os utilitários de linha de comando GNU e páginas de manual. O OpenJDK oferece suporte a Java e o systemd cuida das tarefas de inicialização. Em segundo plano, o Linux 6.14 mantém tudo funcionando.

O gerenciador de arquivos Dolphin
Fedora 42 – O gerenciador de arquivos Dolphin
(tamanho total da imagem: 534kB, resolução: 1920x1080 pixels)

Quando um comando é digitado na linha de comando e o programa desejado não está disponível, há uma breve pausa enquanto o Fedora procura o programa ausente em seus repositórios. Em seguida, ele se oferece para instalar o pacote necessário. Isso torna o processo um pouco mais lento, mas também pode ser um recurso útil ao configurar um novo sistema, pois a distribuição encontra os pacotes necessários.

Executando o navegador Falkon
Fedora 42 – Executando o navegador Falkon
(tamanho total da imagem: 461kB, resolução: 1920x1080 pixels)

Gerenciamento de software:

A edição KDE do Fedora usa o Discover como seu principal gerenciador de software. O Discover tem uma abordagem moderna, onde podemos navegar por categorias de software e ver aplicativos de desktop listados com seu ícone e uma breve descrição. Ao lado de cada entrada, há um botão de download no qual podemos clicar para obter o pacote. Clicar na entrada de um aplicativo exibe uma descrição completa e uma captura de tela.

O centro de software Discover
Fedora 42 – O centro de software Discover
(tamanho total da imagem: 695kB, resolução: 1920x1080 pixels)

Alguns aplicativos são listados no Discover várias vezes. Isso ocorre porque o Discover se conecta aos repositórios de pacotes RPM do Fedora e aos repositórios Flatpak. Os itens disponíveis como pacotes Flatpak têm um pequeno rótulo “Flatpak” à direita da entrada. Por padrão, o Fedora se conecta aos seus próprios repositórios, exclusivos para software livre, e a um repositório Flatpak personalizado, específico do Fedora. Podemos habilitar repositórios RPM de terceiros na janela de boas-vindas ou na página de configurações do Discover. Também podemos habilitar o repositório Flathub para obter acesso a mais pacotes Flatpak.

No primeiro dia em que usei o Fedora, o Discover encontrou 254 novos pacotes para atualizar, que tinham cerca de 2 GB de tamanho. Isso é quase equivalente a baixar novamente o ISO inteiro da distribuição. Depois que novas atualizações são obtidas, elas não são aplicadas imediatamente. O sistema aguarda até que reiniciemos a distribuição e, em seguida, pausa o processo de inicialização para aplicar as atualizações. Isso pode levar vários minutos e tem um toque irritantemente estilo Microsoft, já que a maioria das distribuições Linux aplica atualizações dinamicamente enquanto o sistema está em uso.

O Discover é uma maneira conveniente de gerenciar software, mas também existem opções de linha de comando. Podemos usar o gerenciador de pacotes DNF do Fedora a partir do console para gerenciar pacotes RPM tradicionais e podemos executar o comando flatpak para gerenciar pacotes Flatpak. Ambos os comandos funcionaram para mim. Acho que a versão mais recente do DNF está mais rápida do que era no passado, ou talvez esteja armazenando resultados em cache com mais frequência. De qualquer forma, o DNF pareceu mais rápido desta vez do que no passado e apreciei a limpeza e organização da saída do DNF. Algo que me surpreendeu, porém, é que, na primeira vez que executei o DNF, ele me pediu para verificar uma chave de repositório. Isso provavelmente desanimará novos usuários, que podem não saber por que estão sendo questionados sobre a segurança do repositório e se ela deve ser aceita. Esse tipo de coisa geralmente é tratado discretamente em segundo plano em outras distribuições Linux.

Outras observações

Ainda sobre o gerenciamento de software, a primeira vez que abri o Discover, ele relatou que estava verificando atualizações de software, mas depois a área de trabalho travou. O papel de parede desapareceu, o painel travou e o Discover parou de responder. Foi necessário um hard reset para restaurar a distribuição. Isso também aconteceu no dia seguinte, depois de instalar novos aplicativos e tentar fechar o Discover. Aconteceu mais tarde, quando eu estava trabalhando em outro aplicativo (não me lembro qual neste momento). Resumindo, a área de trabalho do Plasma estava instável.

Como experiência, baixei o pacote X11 para o Plasma ( plasma-workspace-x11).) e entrei no Plasma na sessão X11. Isso teve alguns efeitos interessantes. Um deles foi que o desktop parou de travar a cada poucas horas. A segunda grande mudança foi o desempenho. Os aplicativos iniciaram mais rápido e os menus responderam mais rápido do que quando eu estava usando a sessão Wayland. O terceiro benefício foi que a sessão X11 usou muito menos memória - 800 MB de RAM foram liberados usando a sessão X11 em vez do Wayland. Este último ponto me surpreendeu, pois, normalmente, a sessão Wayland e a sessão X11 de um desktop tendem a usar aproximadamente a mesma quantidade de recursos. No entanto, a sessão X11 do Fedora usou cerca de 1,8 GB de RAM em comparação com os 2,5 GB do Wayland.

Anteriormente, mencionei que o Fedora usará por padrão um volume Btrfs como seu sistema de arquivos padrão. Gosto disso porque o Btrfs tem alguns recursos interessantes, como suporte a vários discos e snapshots. Infelizmente, o Fedora não faz nada com essa tecnologia. Alguns sistemas operacionais, como o openSUSE e o FreeBSD , tiram snapshots automaticamente durante as atualizações. Outros, como o Linux Mint , vêm com ferramentas de snapshot integradas. O Fedora parece não oferecer nenhum utilitário Btrfs ou recursos automatizados para trabalhar com volumes de armazenamento.

Tentando criar snapshots com Timeshift
Fedora 42 – Tentando criar snapshots com Timeshift
(tamanho total da imagem: 514kB, resolução: 1920x1080 pixels)

Decidi adicionar um utilitário Btrfs e instalei o pacote Timeshift dos repositórios RPM do Fedora. O Timeshift não funciona com o layout Btrfs padrão do Fedora. Isso me parece estranho, pois significa (dependendo do ponto de vista) que ou o Fedora configurou os subvolumes Btrfs de uma forma incompatível com ferramentas populares, como o Timeshift, ou o Fedora empacotou um aplicativo que não funciona com sua configuração Btrfs padrão, o que parece uma perda de tempo.

Quanto aos aplicativos que não funcionaram, gostaria de mencionar o aplicativo de código QR. Essa ferramenta escaneia códigos QR para revelar o texto armazenado neles. Ela também pode alternar entre os modos e gerar códigos QR com base no texto que digitamos. Há uma opção para salvar códigos QR, presumivelmente para que possamos compartilhá-los ou imprimi-los em outro aplicativo. No entanto, o utilitário não salva arquivos. Quando a janela de diálogo abrir/salvar aparece, qualquer novo nome de arquivo que fornecemos resulta no erro: “O nome do arquivo não pôde ser encontrado”. Parece que os desenvolvedores misturaram a lógica de abrir/salvar e, quando tentamos salvar um arquivo, ele verifica se o arquivo está disponível para ser aberto.

Tentando salvar uma imagem de código QR
Fedora 42 – Tentando salvar uma imagem de código QR
(tamanho total da imagem: 558kB, resolução: 1920x1080 pixels)

Tentei contornar isso criando um novo arquivo vazio (chamado hello.png ). Então, quando fui salvar meu novo código QR, selecionei esse arquivo vazio como o nome que eu queria usar. Isso pareceu funcionar e o aplicativo pareceu salvar meu código QR em hello.png . No entanto, o arquivo permaneceu vazio (zero bytes de tamanho), demonstrando que a funcionalidade de salvar ainda não estava disponível na ferramenta de código QR.

Conclusões

Muitas das minhas experiências com o Fedora foram frustrantes ou decepcionantes, pelo menos ao usar as opções padrão. Alguns desses eram problemas bem menores. Por exemplo, eu estava ansioso para experimentar o novo instalador do sistema com sua interface simplificada, mas parece que a edição KDE ainda está usando apenas o instalador clássico, enquanto a edição GNOME/Workstation oferece o novo instalador . Ter os dois sabores usando instaladores diferentes faz parecer que o Fedora ainda não vê verdadeiramente a edição KDE como estando em pé de igualdade com a edição GNOME.

Ter o zRAM habilitado provavelmente faz sentido em algumas situações. Sei que algumas pessoas o consideram uma ferramenta útil, mas acabou saindo pela culatra no meu caso, fazendo minha CPU acelerar. Isso, por si só, não seria um grande problema, mas reativar o dispositivo zRAM depois de desativá-lo explicitamente é frustrante. Deu-me a impressão de que a distribuição estava lutando contra meus esforços.

Alguns elementos funcionaram bem para mim. O Discover é um centro de software competente e o painel de Configurações do Sistema do KDE funcionou bem para mim. Algumas das configurações padrão do Plasma não são do meu agrado, mas a área de trabalho é extremamente flexível e a maioria dos recursos pode ser ajustada.

O gerenciador de pacotes DNF parece mais rápido agora do que era no passado e sua saída está claramente organizada. Também gosto que o DNF use palavras claras em inglês para seus comandos de ação.

Voltando ao lado “contra” das coisas, forçar o Plasma a usar uma sessão Wayland por padrão (nenhuma sessão X11 está disponível no sistema) parece prematuro. A sessão Wayland do Plasma é visivelmente mais lenta e com muito mais RAM do que sua sessão X11. A sessão do Wayland também não era estável. O X11 provavelmente deveria ser o padrão ou, pelo menos, estar disponível como uma opção de fallback sem que o usuário precise procurar e instalar manualmente os pacotes do X11.

Gosto que o Fedora 42 esteja facilitando a adição de repositórios de terceiros, como Flathub e RPMFusion. Nas primeiras versões do Fedora, isso exigia que o usuário soubesse que as opções de terceiros existiam, as encontrasse e as adicionasse manualmente. O Fedora 42 torna a ativação de repositórios de software de terceiros tão simples quanto clicar em uma caixa na janela de boas-vindas.

O Fedora é uma distribuição de ponta e haverá algumas surpresas ao surfar na onda do progresso. O Fedora 42 oferece alguns bons novos recursos e algumas conveniências interessantes, mas também tropeça em alguns problemas que não foram testados o suficiente. A entrada do menu de inicialização UEFI foi um pequeno exemplo; a memória inchada e os problemas de estabilidade da sessão Wayland do KDE foram outros problemas claros. Parece que o novo instalador do sistema foi lançado às pressas na versão Workstation, mas talvez não esteja disponível há tempo suficiente para ser introduzido na edição KDE.

Quem quiser uma prévia do que está por vir para o Red Hat Enterprise Linux no futuro ou quiser testar algumas das versões mais recentes de pacotes provavelmente apreciará o Fedora 42, apesar de suas bordas irregulares. Quem procura uma distribuição desktop confiável, com funcionamento suave e pronta para uso provavelmente ficará decepcionado com este lançamento.

Hardware usado nesta análise

Meu equipamento de teste físico para esta análise foi um laptop HP DY2048CA com as seguintes especificações:

Processador: Intel(R) Core™ i5-1135G7 de 11ª geração a 2,40 GHz
Exibição: vídeo integrado Intel
Armazenamento: unidade de estado sólido Western Digital de 512 GB
Memória: 8 GB de RAM
Dispositivo de rede sem fio: Intel Wi-Fi 6 AX201 + placa de rede sem fio BT

ruanelivelton18 · Abril 21, 2025, 9:19pm

Padrão fedora e surpreendente no fim das contas, e como usar um windows não “terminado”(Beta eterno como dizem por aí)kkkk

frc_kde · Abril 22, 2025, 1:37am

Instalei o Fedora 42 em “Linux8” (aproveitando a “Home8” que era do Slackware), e mandei instalar o bootloader em EFI2:

Agora, tenho 2 bootloaders chamados “Fedora”:

Testei o bootloader do Fedora 41 – levou corretamente ao Grub do Fedora 41 – e carregou corretamente o Fedora 41.

Só que, agora, o Fedora 41 ganhou +8 GiB de Swap zRAM. – Total, 19 GiB Swap:

Agora, vou testar o bootloader do Fedora 42…

… mas primeiro, vou verificar se o openSUSE, o Arch, o Mageia, o Void, o PCLinuxOS, o MX Linux foram afetados por essa brincadeira.

frc_kde · Abril 26, 2025, 6:10pm

Uma coisa interessante do Jesse Smith, é que age como um usuário impaciente, mal-informado, reclamão – em suma, o “consumidor padrão”.

1ª sessão Live: - Esqueci de verificar o uso inicial de RAM. – Fui abrindo Dolphin, KWrite, Gwenview, Konsole, System Settings, Welcome Center, Firefox, Plasma System Monitor… e com tudo isso aberto, o System Monitor indicou sempre uso de RAM entre 4,0 e 4,3 GiB RAM.

Quando abri também o instalador Anaconda, o uso de RAM subiu para 5,0 GiB:

Depois de concluir a instalação e fechar o Anaconda, o System Monitor voltou a indicar uso de 4,3 GiB RAM:

2ª sessão Live: - Carreguei novamente uma Live Pendrive, só para verificar o uso de RAM “idle” – ou seja, “rodando só o desktop”, como diz Jesse. – No console virtual tty4, o top indicou uso de 1.909,5 ~ 1.921,2 MiB RAM (1,86 ~ 1,88 GiB).

Tentei ordenar a lista dos aplicativos / processos pelo uso de RAM – mas bastou teclar “shift+M”, para o top pular para 2.267 MiB RAM (2,21 GiB).

Depois disso, abri somente o Plasma System Monitor, e ele indicou 2,0 GiB.

Encontrei 16 processos Akonadi em execução, e mandei encerrá-los, pelo próprio System Monitor. – Então, ele passou a indicar uso de 1,9 GiB RAM:

Tanto na 1ª sessão Live, quanto na 2ª sessão Live:

Minha partição Swap não foi montada
A Swap de 8 GiB em zRAM foi criada – mas não foi usada. – Zero uso, do começo ao fim.
Não percebi nenhuma lentidão – nem percebi nenhuma troca incessante de dados entre a RAM e a zRAM (ou vice-versa). – Como é isso? Faz barulhinho??

Hardware:

   CPU: 6 × Intel® Core™ i5-9400 CPU @ 2.90GHz (min / max: 800 ~ 4100 MHz)
  iGPU: Intel UHD Graphics 630 (Desktop)
   RAM: 15.5 GiB of RAM

frc_kde · Maio 5, 2025, 8:45pm

Depois de fazer minhas configurações regulares – remover PIM, PackageKit, desativar alguns serviços etc. – o uso de Memória RAM acabou emparelhando com o da instalação antiga (que agora já atualizei para Fedora 42, também).

E continuam emparelhados, após essas 2 semanas.

Resumo aqui.

Vou manter a instalação nova por mais algum tempo – e depois vou deletar, pois não compensa fazer todas as configurações que já fiz na instalação antiga, ao longo de 5 anos.

kalebepsouza · Maio 5, 2025, 11:30pm

Apenas curioso. Por que tu desativa esses serviços/pacotes?

kalebepsouza · Maio 5, 2025, 11:54pm

Descobri esse bug quando fui realizar a instalação do Fedora 42, se eu não fosse um usuário avançado não teria percebido que ele tinha adicionado uma entrada na BIOS/UEFI e ainda deixado desabilitado o que me impediu de inicializar o pendrive novamente no mesmo notebook, mas rapidamente percebi e entrei na BIOS reativado a entrada para que o pendrive pudesse ser detectado para instalação no meu de boot.

Não tive esse problema. Na verdade, o consumo ficou parecido com o Kubuntu no mesmo notebook que pelo que me lembro fica em torno de 1.4 GB no total apenas o Desktop executando.

Na verdade, o Fedora usa zRam por padrão, o que não é uma “swap falsa”, mas apenas listada como um dispositivo de swap por mera nomenclatura para entendimento do usuário do sistema. Em resumo, o sistema “enxerga” Zram, Swap (tradicional) ou zSwap todos como dispositivos de Swap, pois tem a função de auxiliar a memória principal.

Por hora foi implementado apenas na versão gnome. Tenho certeza que tinha alguma nota oficial em sites e fóruns detalhando isso na versão KDE.

Não. Se vc criar uma partição Swap no modo de instalação personalizada, ela será criada normalmente e funcionara em conjunto com o zram, mas com uma prioridade menor (se a ram e o zram “encher”) ela será usada. Em resumo pode continuar usando uma partição swap ou como arquivo normalmente.

Isso pode ser alterado nas configurações na edição KDE para serem aplicadas as atualizações de forma imediata, ou vc pode rodar um sudo dnf upgrade também. Lembrando que atualizações de Kernel só serão aplicadas ao reiniciar (por um motivo obvio).

frc_kde · Maio 6, 2025, 2:42am

Acho que o hardware do Jesse Smith estão com urucubaca, ou caveira de mula (*), ou despacho na encruzilhada – ou ferrugem, cansaço, hérnia de disco, leseira – ou alguma configuração errada na “UEFI Bios”:

Na edição de hoje (5 Maio 2025), experimentando o CachyOS, aconteceu de novo:

O desktop Plasma ao vivo era anormalmente lento para responder a entradas e surpreendentemente lento para iniciar aplicativos. Quando executei a distribuição no VirtualBox, o sistema ao vivo levava cerca de três segundos para abrir o menu de aplicativos, dois segundos para pesquisar um inicializador no menu e até onze segundos se passavam entre clicar no botão Desligar e ver a janela de confirmação. Quando executei o CachyOS no meu laptop, a experiência foi mais responsiva, cerca de duas a três vezes mais rápida, mas ainda assim é anormalmente lento em comparação com a maioria das outras distribuições que executam sessões ao vivo no mesmo hardware. Isso me surpreendeu, tanto porque a missão declarada do CachyOS é ser rápido

Na resposta #35, alguém desmentiu:

Já instalei o CachyOS várias vezes, em várias máquinas, e nunca notei que ele fosse particularmente lento, tanto ao vivo quanto instalado.

Na resposta #43, outro desmentido – e uma possível explicação: – Seria “hardware antigo”? (i5 11ª geração!):

Sua experiência foi o oposto da minha. O CachyOS tem sido rápido para mim e funcionou perfeitamente. Gostaria de saber em que tipo de hardware você o estava executando. O ponto principal do CachyOS é que ele recompila muitos repositórios de arquitetura com sinalizadores específicos para arquiteturas x86_64 mais recentes. É por isso que sempre alerto quem o recomenda para todos, pois não acho que você obteria muitos benefícios do CachyOS em hardware mais antigo.

Bom, o meu é i5 de 9ª geração, também com iGPU Intel – e não vi nenhuma lentidão na sessão Live, nem uso excessivo de RAM.

Depois de instalado e “enxugado”, o meu ficou em 1,3 GiB RAM, só o desktop. – Mas 1,4 GiB RAM é uma boa marca, para o Fedora instalado.

Na sessão Live, sem Conky nas capturas de tela, só posso falar o que escrevi antes: 2,0 GiB RAM, passando a um máximo de 4,3 GiB RAM com vários aplicativos GUI abertos; e 5 GiB RAM depois de abrir também o instalador Anaconda.

Estou usando o Arch neste momento, com Dolphin, Chrome, Kate, Whatschrome, Gwenview, KWrite, e dá 5 GiB RAM.

Exato. Já ouvi falar nessa opção (do Discover?), mas nunca usei. – Uso dnf, e atualiza na hora, enquanto faço outras coisas no computador.

Só no upgrade de versão, usando o dnf-plugin-system-upgrade, é que as atualizações são “aplicadas” após um reboot, e antes de carregar o DE atualizado. – Mas isso faz todo sentido. Upgrade de versão mexe com todas as entranhas do sistema. Não daria pra fazer com o sistema + DE (antigos) em funcionamento. – E parece uma boa fórmula. Fiz upgrade desde o 31 até o 42 (6 anos!), sem nunca apresentar nem 1 problema, por menor que fosse.

A resposta simples é: “porque não uso”.

Não uso KOrganizer, KMail, Akregator, KAddressbook – então, não faz sentido deixar 16 ou 17 processos Akonadi rodando o dia inteiro, 365 dias por ano – ou mesmo, deixar tudo isso instalado. – Basta você abrir 1 deles, por descuido, para botar em andamento uma “orquestra de 300 instrumentos”… que vai continuar em execução, pelo resto do milênio.

A suíte PIM pode ser muito valiosa em um ambiente corporativo – e já vi usuários domésticos que também gostam muito – mas para mim, não tem utilidade.

Já vai fazer 10 anos que descobri que também não uso nada que precise do File Search. – Não ponho Tags, nem Avaliações (0 a 5 estrelas), nem Comentários nos meus arquivos, nem dependo de coisas como “Hoje”, “Ontem”, “Anteontem”, para encontrá-los. – E como não uso KMail, não preciso de ajuda para encontrar “onde salvei aquele anexo que fulano de tal me mandou pelo KMail, não sei quando, nem com qual nome”.

Sei onde salvo meus arquivos, e em quais partições & pastas – e uso nomes-de-arquivo relevantes. – É muito fácil e rápido encontrar qualquer arquivo pela busca simples do Dolphin (CTRL+F) ou pela busca avançada (KFind), mesmo em um HDD de 1 TB – sem necessidade de passar o ano inteiro indexando tudo, o dia inteiro, ano após ano, durante 10 anos, 20 anos.

Enfim, lido bem com o navegador (Chrome) – sem precisar que a busca do Menu me apresente 300 bookmarks, 300 sites que visitei nos últimos 10 anos etc. – Meu Menu é simples. Só autorizo procurar Aplicativos.

É como guardar tudo, porque “um dia posso precisar”. Depois de 10 anos, sua casa vira um entulho – e você não encontra nem mesmo as coisas que costuma usar com frequência. – Um dia desses, despejei 300 kg de tralha, o caminhão do lixo seletivo ficou meia-hora só recolhendo (rs). – Ao terminar, senti um alívio enorme. A vida ficou mais leve, mais simples, mais fácil. Tirei 300 kg das costas.

Minha vida melhorou tanto, que já estou de olho em mais umas coisinhas para desapegar.

(*) O Discourse não permite “caveira de burroughs”.

kalebepsouza · Maio 6, 2025, 12:55pm

Entendi. Obrigado pela resposta! Obtive várias informações que possam ser uteis.

msteles · Maio 6, 2025, 3:04pm

Também não uso esse cara e deixar ativo acababa consumindo recursos à toa.
Você só desativa ou remove os pacotes? Tenho um certo receio de remover os pacotes e dar algum problema no futuro, então apenas desativo a inicialização automática do Akonadi.

msteles · Maio 6, 2025, 3:06pm

Estou precisando fazer isso por aqui também. Mas deve dar mais de 300kg.

frc_kde · Maio 6, 2025, 9:53pm

Prefiro remover – pois abrir qualquer um deles, mesmo que feche de novo imediatamente, já faz com que a suíte toda fique rodando em segundo plano:

Faço isso desde 2016, quando li no Google+1 (Plus One) uma explicação bem estruturada e clara sobre o PIM e como removê-lo. – Na época, fiz uma pesquisa no site da KDE e.V. para aprender tudo que pude sobre o PIM e seus componentes. – Fiz essas anotações aqui.

O importante é ler com atenção a lista de dependências que serão removidas.

Na época, me chamou atenção que o KDE Neon – feito pelos criadores do Kubuntu “saídos” da Canonical e abrigados na KDE e.V. – não instalava a suíte PIM, por padrão.

Nesses 9 anos, alguns pacotes deixaram de ser incluídos – e alguns nomes pode ser ligeiramente diferentes, de uma distro para outra. – Em geral, basta remover os “cabeças”, que o resto vai junto. E depois, remover os pacotes que ficaram órfãos:

# dnf remove korganizer kmail akregator kaddressbook akonadi-server mariadb-common
(...)
 Removing:          79 packages
(...)
# dnf clean all
Removed 24 files, 19 directories. 0 errors occurred.

No openSUSE, tive de bloquear, para não serem instalados de novo – devido aos “patterns”:

The following 37 items are locked and will not be changed by any action:
 Available:
  akonadi-calendar-tools akonadi-calendar-tools-lang akonadi-import-wizard akonadi-import-wizard-lang akonadi-mime akonadi-plugin-calendar
  akonadi-plugin-contacts akonadi-plugin-mime akonadi-search akonadi-search-lang pattern:games pattern:kde_pim kdepim-addons
  kdepim-addons-lang kdepim-runtime kdepim-runtime-lang kmail-account-wizard kmail-account-wizard-lang kmailtransport kmailtransport-lang
  ktnef libkdepim-lang libksieve libksieve-lang libpackagekit-glib2-18 mbox-importer mbox-importer-lang messagelib messagelib-lang PackageKit
  PackageKit-backend-zypp PackageKit-branding-openSUSE PackageKit-branding-upstream PackageKit-devel PackageKit-gstreamer-plugin
  PackageKit-gtk3-module PackageKit-lang

Depois de esvaziar a tralha, encontrei coisas que estavam sumidas – como o pacotinho de parafusos de fixação de HDDs / SSDs e outros dispositivos.

msteles · Maio 7, 2025, 12:07pm

Obrigado pela resposta e pelo detalhado relato apontado pelo link.

frc_kde · Junho 4, 2025, 1:07pm

No final de Abril, finalmente fiz upgrade da minha “instalação antiga” – de 41 para 42:

Depois disso, parei de atualizar a “instalação nova” – mas deixei por mais um tempo, para o caso de querer verificar alguma coisa.

Em 1º Junho, finalmente deletei a “instalação nova”. – Ou seja, formatei a partição Linux8:

Deletei a respectiva “entrada” na UEFI Bios:

# efibootmgr
BootCurrent: 0000
Timeout: 10 seconds
BootOrder: 0000,0009,0006,0004,0010,000C,0001,000D,0011,0002,0003,0005,0007
Boot0000* opensuse      HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\opensuse\grubx64.efi)
Boot0001* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0002* Fedora        HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/File(\EFI\FEDORA\SHIMX64.EFI)
Boot0003* UEFI:CD/DVD Drive     BBS(129,,0x0)
Boot0004* pclinuxos     HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\PCLINUXOS\GRUBX64.EFI)
Boot0005* UEFI:Removable Device BBS(130,,0x0)
Boot0006* arch_grub2    HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\ARCH_GRUB2\GRUBX64.EFI)
Boot0007* UEFI:Network Device   BBS(131,,0x0)
Boot0009* Mageia_grub   HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/File(\EFI\MAGEIA_GRUB\GRUBX64.EFI)
Boot000C* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\DEBIAN\GRUBX64.EFI)0000424f
Boot000D* Void_grub     HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/File(\EFI\VOID_GRUB\GRUBX64.EFI)
Boot0010* MX_grub       HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/File(\EFI\MX_GRUB\GRUBX64.EFI)
Boot0011* Fedora        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\FEDORA\SHIM.EFI)0000424f

# efibootmgr -b 2 -B
BootCurrent: 0000
Timeout: 10 seconds
BootOrder: 0000,0009,0006,0004,0010,000C,0001,000D,0011,0003,0005,0007
Boot0000* opensuse      HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\opensuse\grubx64.efi)
Boot0001* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0003* UEFI:CD/DVD Drive     BBS(129,,0x0)
Boot0004* pclinuxos     HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\PCLINUXOS\GRUBX64.EFI)
Boot0005* UEFI:Removable Device BBS(130,,0x0)
Boot0006* arch_grub2    HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\ARCH_GRUB2\GRUBX64.EFI)
Boot0007* UEFI:Network Device   BBS(131,,0x0)
Boot0009* Mageia_grub   HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/File(\EFI\MAGEIA_GRUB\GRUBX64.EFI)
Boot000C* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\DEBIAN\GRUBX64.EFI)0000424f
Boot000D* Void_grub     HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/File(\EFI\VOID_GRUB\GRUBX64.EFI)
Boot0010* MX_grub       HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/File(\EFI\MX_GRUB\GRUBX64.EFI)
Boot0011* Fedora        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\FEDORA\SHIM.EFI)0000424f

E atualizei meu “Grub-padrão” (do openSUSE), para eliminar a instalação deletada:

Rimana21 · Junho 5, 2025, 2:24am

Eu não sei se esse é um recurso secreto no fedora mas achei muito interessante bem parecido com o linux mint, estou me referindo o “calamares” embutido junto ao anaconda do fedora.
Eu confesso aqui que sou como milho cozido quando o assunto é particionamento linux (um pamonha).

Existem vários tipos de instalação no anaconda, entre uma delas é re-alocar o espaço livre de uma outra distro já instalada sem precisar ter que usar o gparted ou particionamento avançado, isso para mim foi um baita presente do fedora, eles colocaram um “calamares” escondido alí. Assim você pode instalar o fedora realocando o espaço livre de outra distro se quiser manter o dual boot.

frc_kde · Junho 5, 2025, 10:05pm

Aí, deu 1 nó nos meus 2 neurônios.

Tenho a maior dificuldade para lembrar as diferenças entre os instaladores Anaconda e Calamares. – Quando preciso pensar nisso, sou obrigado a Googlar, para lembrar qual deles é um, e qual deles é o outro.

Um dentro do outro (ou vice-versa), até me dá curto-circuito.

Lembro melhor as diferenças em relação ao “antigo instalador Debian” (argh!), o antigo Ubiquity dos Buntus, o Drak ou similar do Mageia ou do PCLinuxOS, e o YaST2 do openSUSE (já vi dizer que será aposentado, uma pena).

Talvez a aposentadoria do YaST2 seja sinal de que estamos chegando a um “instalador universal” – mas, de repente, não sei qual é: – Anaconda? Calamares? Nessa hora, só o Google me salva.

Lembro vagamente que na seção “Particionamento” existem (ou existiam) diferenças bem visíveis – mas é a seção que uso menos. – Faço meu particionamento antes de começar, e durante a instalação apenas “escolho” entre as partições que já tenho.

Rimana21 · Junho 5, 2025, 11:48pm

Pois para mim já queimou o meu transformador.
Deixe explicar como vejo os dois instaladores:

1° O Calamares é um instalador do tipo “NEXT, NEXT e FINISH” ou seja, básico do básico. Qualquer pessoa com pouco conhecimento saberia como instalar o sistema.

2° Anaconda: usar esse instalador é o mesmo que tentar resolver uma equação exponencial

Realmente não é pra qualquer um.
O Fedora é um ótimo sistema projetado de acordo e com instalador a altura.

frc_kde · Junho 6, 2025, 8:59pm

Acho que quase todos são assim – e isso é uma das coisas que me confundem, entre o Calamares e o Ubiquity – pois o “novo” Ubiquity também tinha um painel à esquerda, com as etapas sucessivas:

Isso aqui me parece o Ubiquity “novo” – KDE Neon, Janeiro 2020 – com as etapas: Language, Keyboard, Wireless, Software, Disk Setup, Timezone, User Info, Install:

Esse aqui, me parece o Calamares, até porque anotei isso no nome do Print (rs) – Março 2020 – com as etapas: Wellcome, Location, Keyboard, Partitions, Users, Summary, Install, Finish:

Ao passo que o Anaconda “tradicional” é “não-linear”. – Usa a estrutura de “Concentrador & Raios” (Hub & Spoke) – em que você pode percorrer as etapas em qualquer ordem, e quantas vezes quiser, fazendo e desfazendo opções:

(Ainda não conheço o Anaconda “novo”, da edição Fedora Gnome: – Só instalei a edição KDE).

Você só pode prosseguir, depois que os 6 módulos (ou, “raios”) estiverem devidamente configurados. – Ou seja, quando desaparecem os avisos em vermelho – indicadores de que falta alguma coisa, ou de que algo não está 100% “aceitável”:

Infelizmente, essa estrutura “Hub & Spoke” não ficava nem um pouco clara. – Não tem um “Ok” embaixo, à direita (como estamos acostumados). – Em vez disso, poderia ter uma "seta para a esquerda, lá no alto, como já é comum em vários aplicativos GUI, significando “Home”. Mas, tudo que tem, é um botão azul escuro, em fundo azul-mais-escuro, escrito “Pronto”:

Exemplo de aplicativo GUI com seta para voltar à sua “Home”:

Mas essas coisas – ser “Linear” ou “Hub” – acho que não são o que causa dificuldades a você.

Tenho a impressão de que sua dificuldade esteja na complexidade do “Particionador” do Anaconda. – É preciso escolher 1 disco… Em seguida ter o cuidado de trocar o “esquema”, de BtrFS para “Standard Partition”… Depois procurar as partições desejadas – escondidas em grupos chamados “Unknown Linux”, “Mageia”, outro “Unknown Linux”, “Debian GNU”, e “Unknown”:

(Observe como o botão “Pronto” é quase invisível, no alto à esquerda).

Anos atrás, em vez de BtrFS, o Anaconda o Fedora oferecia “LVM”, por padrão! – Dois “esquemas” igualmente inadequados para um novato, que tenta instalar uma distro Linux pela primeira vez em sua vida!

Um desses dois “Unknown Linux” devia ser o Void (ou ambos, sei lá) – e o tal “Debian GNU” era, na verdade, minha instalação do MX Linux. – Esse “agrupamento” pode ser bom, para evitar que a gente formate e apague uma distro que a gente queria manter… Mas neste caso, falhou, por não identificar o Void, e chamar o MX Linux pelo nome errado.

(A “culpa” deve ser do Void e do MX Linux, claro! – Eles deveriam se adequar ao Anaconda do Fedora, huashuashuash!).

Outra coisa curiosa desse “agrupamento”, é que minhas partições EFI e Swap aparecem – repetidas – em todos os “grupos”, claro! Afinal, são comuns a várias distros.

Em 2020, achei mais fácil lidar com essa embrulhada toda – porque eu só tinha 1 SSD – só tinha instalado o PCLinuxOS, o openSUSE, o KDE Neon (todas corretamente identificadas pelo Anaconda)… e já tinha criado as demais partições (inclusive a que iria usar para o Fedora, sem Home e sem Swap separadas: tudo muito simples):

Deus me livre, de tentar usar esse “particionador” do Anaconda “tradicional”, para fazer qualquer coisa – exceto “escolher” partições (preparadas antes).

Mas, há muitos anos, parei de usar o “particionador” – de qualquer “instalador”! – para criar partições, encolher partições etc.

Isso pode parecer bobagem, para a maioria dos usuários – que, em geral, usam distros “parecidas”, muitas delas com o Calamares, cada vez mais “familiar” – e têm apenas 1 outro S.O., muitas vezes em outro SSD diferente.

No meu caso, tenho 8 a 12 distros em dualboot – com 28 partições amontoadas lado a lado – e qualquer vacilo seria um desastre muito chato.

Por isso, há muito tempo, só faço particionamento pelo GParted – cujo comportamento já conheço: – É sempre igual – e sempre uso rótulos (Label), para identificar todas as partições com clareza: Linux1 a Linux12, Home1 a Home12, Warehouse, Midia, Works, Sites.

E mesmo assim, já cometi erros, de dar raiva.

Cada “instalador” tem um “particionador” diferente – cada um, com algum comportamento… que não é exatamente “aquele”, que a gente pensou que seria. – Além disso, tenho mania de brincar com distros “esquisitas”, com instaladores inesperados.

Quando instalei o Mageia, em 2017, eu tinha anotado em papel que iria usar a partição sda2 – e também tinha, bem à vista, uma planilha com as partições que iria usar – e mesmo assim, na hora H, formatei a partição sda1… Com isso, perdi uma ótima instalação do KDE Neon (estava perfeita!):

(E isso, porque as partições já estavam prontas: – Era só escolher!).

Não lembro agora o nome do instalador do Mageia.

No PCLinuxOS, o “DrakLive-Install” também é “meio diferente”:

O “particionador” do YaST2 do openSUSE, então, é uma maravilha:

São tantos recursos de exibição, que a gente pode até tropeçar e levar um tombo:

Não vou nem olhar os Prints do “instalador” do Slackware – “semi-gráfico”.

Rimana21 · Junho 6, 2025, 11:06pm

Você tem razão rapaz, eu só aprendi mesmo o básico de particionamento entre instalar do zero ou re-alocar espaço livre para manter o outro sistema. O mesmo vale para o LM, Deepin, BigLinux, Ubuntu e o Peppermint
Do TigerOS, LingmoOS e Gparted são de boa as configurações de particionamento.

Impressionante, 12 distros.
Acredito eu que seus HDDs e SSDs devem ser de 10TB para comportar essas distros.

Nesse exato momento estou com apenas 2 SSDs, um com o Peppermint e o outro dividindo espaço com duas distros. Os 7 restantes estão guardados na gaveta das meias junto com um nvme de 256GB esperando máquina.

rapoelho · Junho 6, 2025, 11:11pm

Há (ou havia) dois Ubiquity: Um em QT, que tem essa barra lateral e outro em GTK que não tem essa barra lateral.

E depois, ele foi refeito em Flutter.

Até instalei a edição Gnome do Fedora um HDD que tenho parado aqui. Até que achei o instalador bem de boa, mas não fiz demais anotações, e esqueci de salvar os Prints num Pendrive que não fosse o do Ventoy (Do’h!).