 |
| Quadro: - Situação das 12 distros instaladas até 11 Junho 2023 |
• Isto não é uma “comparação técnica” entre distribuições Linux — até porque nenhuma delas é uma “instalação padrão” (out of the box). — Isso é apenas um “quadro da situação” das minhas distros neste momento, às vésperas das novas versões do Mageia e do MX Linux.
Todas instaladas em dualboot (multiboot), por segurança. — Se uma distro quebrar, basta reiniciar, escolher outra, e continuar minhas atividades em 2 minutos; e conserto quando tiver tempo. — (O último desastre fatal foi em 2017, quando eu tinha 4 distros, 2 quebraram, e pude resolver com calma, semanas depois).
Me acostumei a mudar de “distro preferida”, a qualquer momento em que me sinta mais confortável com outra — um “distro-hopping em baixa velocidade”. — Se não consigo dominar uma distro logo no começo, continuo tentando nas horas vagas, durante meses, ou anos.
Tenho escolhido distros que cubram os “ramos” principais da “árvore de distros Linux” — diferentes filosofias, diferentes sistemas init, diferentes modos de instalação, de empacotamento e gerenciamento de pacotes etc. — para não ficar dependente de nenhuma empresa ou comunidade, em caso de falência, compra, venda, incorporação, mudanças drásticas, ou outra inconveniência.
Para lidar com essa “creche”, preciso lembrar as características das várias distros que tenho, anotar o que já consegui em cada uma, e o que ainda falta aprender. — O Quadro (acima) me ajuda a ter uma visão geral.
Os itens avaliados mudam com o tempo. — Hoje, quase não preciso do Wine; o corona-cli já não é tão necessário; e o speedtest-cli deixou de ser útil; mas ainda registro, até que outras tarefas tomem seus lugares. — Em 2017, minhas preocupações eram bem outras (Fevereiro, Junho).
- 2024 Agosto - Adicionei algumas observações sobre o que aconteceu desde a publicação original dessas notas — mas sem entrar em detalhes, pois isto exigiria reescrever quase tudo.
 |
| 2024: eliminei 4 distros, para simplificar minha vida |
- 2024 Dezembro - Eliminei 4 distros, nas quais perdi interesse: — KDE Neon, Slackware, Manjaro e Redcore. — Bastou carregar outra distro, desmontar suas partições-raiz e formatá-las (preservando as partições /home). — Por fim, atualizei o Grub para refletir a nova situação; e editei o arquivo de configuração do Conky. — Estou pensando em experimentar o Antix.
Índice
- Visão geral
- Label
- Partições-raiz
- Tipo de lançamento
- Kernel
- KDE Plasma
- Software init
- Servidor gráfico
- DE Console
- Sistema de arquivos
- Empacotamento e gerenciadores de pacotes
- User ID
- Data da instalação
- Espaço ocupado na partição-raiz
- Tempo de boot
- Uso de Memória RAM
- GoogleEarth
- Sincronização do Google
- Foliate
- corona-cli
- yt-dlp
- speedtest-cli
- Wine
- Outros itens
- Grub
- uDisks2
- Weather
- Exif
- Pré-visualização de arquivos no Dolphin
- Kim4
- Mudanças nos aplicativos do KDE
- Atalhos personalizados no Wayland
- Gerenciadores de pacotes
- Distros “preferidas”
- Um passo de cada vez
- Hardware
Visão geral
 |
| Mensagens de erro de Rede na inicialização de várias distros Linux |
Label - Tanto as partições-raiz quanto os hostname's são numerados (Linux1 a Linux12), para facilitar minha vida no dia-a-dia. — Recebo mensagens de erro durante o boot de algumas distros, talvez por não aceitarem maiúsculas e números (ou talvez, por conflito entre systemd e /etc/hostname) — mas não há problemas de conexão.
 |
| Redistribuição das distros entre 2 SSDs Sata III |
Partições-raiz - Em Maio 2023, instalei um segundo SSD Sata III e “movi” para ele metade das distros. — Com isso, deixei de usar HDD (Swap, partições /home, partições de documentos) — o que reduziu bastante o tempo de boot de todas as distros.
Distribuir 12 distros em 2 SSDs era minha intenção desde 2020, por uma questão de segurança — e só adiei devido à pandemia.
Tipo de lançamento - O Slackware permanece um desafio, para mim, e desisti de torná-lo “rolling-release” (current), por enquanto. Limito-me a atualizar um ou outro pacote, quando necessário. — O Redcore sofreu algum desastre, e agora também atualizo só um ou outro pacote; por isso, não classifico mais como “rolling-release”, até consertar. Reinstalar não me ensinaria nada, por isso prefiro continuar tentando. — Ambos funcionam bem, exceto por alguns pacotes que ainda faltam.
Kernel - Uso o Kernel que cada distro “traz naturalmente”, e desde 2007 isto só me incomodou 1 vez: — Instalei o Kernel corrente no Arch, e só quando se desentendeu com o Grub é que instalei o LTS, em Março 2023. — No Manjaro, optei pelo Kernel LTS desde a instalação (mas não é o mesmo Kernel LTS do Arch).
KDE Plasma - Todas as distros estão com o KDE — e procuro configurá-las tão “igual” quanto possível, de modo que mal percebo a diferença, ao passar de uma distro para outra. — No Mageia 8, no Slackware 15 e no MX Linux 21, ainda tenho alguns recursos que desapareceram em versões recentes dos aplicativos KDE. Nada que me incomode muito. (Ver “Mudanças nos Aplicativos do KDE”, adiante).
 |
| systemd-analize vs. disponibilidade efetiva do Plasma KDE |
Software init - Apenas no Void, precisei lidar com o Runit, pois fiz a instalação básica e depois adicionei o Plasma KDE. Nenhuma dificuldade. Só não encontrei um comando para exibir sua versão. — Eu raramente uso comandos do SystemD — e nas outras distros, ainda não precisei lidar com o SysV nem com o OpenRC.
O único efeito prático, é que não disponho de uma ferramenta unificada (como o systemd-analyze) para medir com precisão o tempo de boot de todas as distros — mas isso talvez seja bom, pois de nada me serve receber números como 15’’, se o Painel do KDE só se torna disponível, de fato, aos 24’’ uptime:
«Note that these measurements simply measure the time passed up to the point where all system services have been spawned, but not necessarily until they fully finished initialization or the disk is idle»
Servidor gráfico - Só no Fedora, mudei do X11 para o Wayland, para ficar de olho no que promete se tornar o próximo padrão. — Por enquanto, precisei apenas substituir o gnome-screenshot pelo KDE Spectacle — ambos com salvamento automático (commandline in background), sem abrir janela de diálogo GUI. (Ver “Atalhos personalizados no Wayland”, adiante).
DE Console - Localização do ambiente Plasma KDE nos Consoles tty1, tty7 e até mesmo no tty8. — Informação inútil, já que é muito mais rápido tentar logo as 3 alternativas do que procurar “onde foi que anotei” — ao voltar do tty2, que é onde costumo executar comandos fora do ambiente gráfico do KDE.
- 2024 - Em várias distros, agora o KDE usa o tty2
 |
| Partição BtrFS quase “vazia”, vista a partir de outras distros |
Sistema de arquivos - Somente no openSUSE, optei por partição-raiz em BtrFS (com snapshots). Nenhum problema com BtrFS, desde 2017 — mas isso dificulta localizar seus arquivos do sistema, a partir de uma sessão Live USB (ou a partir das outras distros). Para limitar essa dificuldade, mantive as outras distros em partições ext4. — Nenhum problema com a partição /home do openSUSE em XFS, desde 2017.
Empacotamento e gerenciadores de pacotes - O Arch, o Slackware e o Redcore têm modos próprios de empacotamento, que assinalei com asteriscos (*), na falta de outras siglas tão conhecidas quanto “deb” e “rpm” (aceito sugestões). — No openSUSE uso o zypper; no Fedora uso o dnf; no Mageia uso urpmi / urpme etc.; no Void uso xbps; no Redcore procuro usar o sysiphus (embora às vezes tenha de usar o emerge, para algumas tarefas). — No Debian, no KDE Neon e no MX Linux, uso o apt para verificar as atualizações; e o Synaptic para aplicá-las, ou para pesquisar e instalar novos pacotes. — No PCLinuxOS, uso só o Synaptic, para não me confundir com seu apt (apt-rpm). — No Arch, uso o pacman para atualizar o sistema; e só depois uso o yay para atualizar os poucos pacotes do AUR que utilizo. — No Manjaro, uso o pacman e, em seguida, o pamac-cli.
Minha primeira providência, ao instalar uma distro, é remover o PackageKit, responsável pela verificação automática de atualizações. — Deixei apenas no Mageia, que me ofereceu um modo rápido de “nunca verificar”; e no KDE Neon (também desativado), porque os desenvolvedores insistem que devemos usar o comando pkcon (uso pkcon nos upgrades de versão; e às vezes para verificar se o apt / Synaptic está fazendo tudo certo). — Ao remover o PackageKit, a “lojinha” Plasma-Discover também é removida, assim como o Apper do Debian.
Nas distros “deb”, também removo unattended-upgrades, que faz atualizações “de segurança” sem perguntar nem avisar — além de aumentar a fragmentação dos registros (log separado). — Prefiro fazer tudo pelo Synaptic, de modo a ter um Histórico centralizado (e fácil de pesquisar).
Portanto, nada se instala nem se atualiza, exceto quando eu comando manualmente, em geral aos Domingos — e não fico recebendo avisos impertinentes a toda hora.
Ainda não utilizo Flatpaks, Snaps, AppImages. — Utilizo o mínimo de repositórios não-oficiais de cada distro (Packman-Essentials no openSUSE, AUR no Arch, RPM Fusion no Fedora). — Em geral, habilito os repositórios do Google para o Chrome e o GoogleEarth, a serem usados pelo apt / Synaptic / dnf / urpmi / sysiphus etc., mas no Void e no Slackware a atualização precisa ser feita na unha. — No PCLinuxOS, o LibreOffice vem direto da fonte, por um aplicativo específico (não pelo Synaptic). — No KDE Neon, recorri apenas ao PPA do Foliate; mas um dos upgrades instalou automaticamente o PPA do Mozilla Firefox (que nem uso).
Enfim, em todas as distros, instalei o corona-cli pelo comando npm — vem do github, se não me engano. — Tentei o pip algumas vezes, no Arch, no Debian e no Slackware, sem muito sucesso.
User ID - Na minha primeira instalação do PCLinuxOS, o UID padrão era 500, e isso bloqueou o uso mútuo de arquivos com as demais distros, cujos usuários têm UID=1000. — Por isso, agora especifico UID=1000 ao reinstalar o PCLinuxOS. — Nunca tive problemas com GID=100, ou 1001, 1002 etc.
Data da instalação - No meu antigo PC, várias dessas distros foram instaladas a partir de Outubro 2016 (Debian testing) e de 2017 em diante, e continuaram funcionando sem grandes problemas até Janeiro 2020 — quando montei meu PC atual e optei por nova instalação das distros (agora, em UEFI-GPT). — As datas do PCLinuxOS e do MX Linux estão erradas, pois foram reinstalados em Agosto e Outubro 2021, respectivamente.
Em breve, será hora de decidir se vou reinstalar ou apenas fazer upgrade do Mageia e do MX Linux. — Nenhum problema com sucessivos upgrades do KDE Neon e do Fedora (ou do Leap, no antigo PC).
 |
| Espaço liberado após limpar o cache de pacotes baixados |
Espaço ocupado na partição-raiz - Para o openSUSE Tumbleweed, destinei uma partição de 50 GiB, pois os “instantâneos” (snapshots) acumulam-se muito rápido. E limitei bastante o número de snapshots a serem mantidos. — Para as outras distros, destinei partições de 30 GiB — mas no caso do Redcore tive de ampliar para 60 GiB devido ao espaço exigido durante as compilações.
Nas distros em que uso o apt / Synaptic, configurei para sempre esvaziar o cache de pacotes baixados, após completar sua instalação. — No Arch, no Void e no Manjaro, faço uma limpeza do cache de pacotes baixados quando o espaço ocupado começa a aumentar muito. (Não costumo fazer downgrade de pacotes). — Enfim, o espaço ocupado também depende do número de pacotes instalados, quando a distro já vem com muita coisa, ou quando já adicionei muitos pacotes.
Average Boot Time (sec)
Oct 2021 Jun 2023 Diff Delta Jan 2020
openSUSE 42’’ 33’’ - 9 -22% 15’’
Arch 32’’ 19’’ -13 -41%
Debian 23’’ 17’’ - 6 -27%
Fedora 40’’ 36’’ - 4 -10% 15’’
Neon 27’’ 23’’ - 4 -15% 10’’
PCLinuxOS 25’’ 18’’ - 7 -27% 16’’
Mageia 37’’ 18’’ -19 -51%
Slackware 31’’ 15’’ -16 -52%
Void 34’’ 19’’ -15 -43%
Manjaro 31’’ 19’’ -12 -40%
Redcore 14’’
MX Linux 35’’ 22’’ -13 -38%
Tempo de boot - Passo até 1 semana sem reiniciar o computador, por isso, ganhar alguns segundos no boot não é relevante — mas noto que o openSUSE (BtrFS + Snapshots) e o Fedora costumam demorar mais — enquanto o Debian testing e o KDE Neon demoram menos, por exemplo.
Após mover a partição Swap, as partições /home e as partições de documentos do HDD para SSDs Sata III, em Maio 2023, o tempo de boot diminuiu drasticamente (não tenho plano de investir em NMVe, no momento).
Os tempos acima são a média de várias observações (Conky), no momento em que finalmente é exibido o Painel do KDE Plasma. — Apenas no Debian, a montagem automática de 25 partições extras é feita pelo /etc/fstab — enquanto nas outras é feita pelo UDisks2, via KDE System Settings.
Esses tempos eram ainda menores em Janeiro 2020, quando eu ainda não usava partições Swap e /home; e a montagem automática envolvia apenas 3 ou 5 partições extras (todas em SSD Sata III).
RAM usage 10 min uptime (iddle) - just 1 sample
Void 878 MiB
PCLinuxOS 921 MiB
Slackware 940 MiB
MX Linux 940 MiB --- average 967 MiB, for previous 6 samples
Redcore 1,001 MiB
Manjaro 1,031 MiB
Neon 1,049 MiB
Arch 1,059 MiB
Mageia 1,068 MiB
Fedora 1,139 MiB
openSUSE 1,210 MiB
Debian 1,211 MiB
Uso de Memória RAM - Com 16 GB de Memória RAM, não faz diferença se uma distro Linux usa 900 MiB ou 1.200 MiB ao terminar o boot e carregar a sessão Plasma KDE — mas talvez essas anotações possam ser úteis para quem tem um PC mais antigo / mais fraco:
- Os números acima são de 1 única observação — exatamente aos 10 minutos uptime (iddle) — e vale lembrar que oscilam a cada segundo (e de um boot para outro)
- Nenhuma dessas distros é uma “instalação padrão” (out of the box)
- Todas, sem o KDE-PIM — KMail, KAddressBook, KOrganizer etc. — e portanto, sem 17+ processos do Akonadi em execução
- Todas, sem File Search (indexação pelo baloo_file) — que nunca me fez falta para buscas simples no Dolphin (CTRL+F), ou avançadas (KFind). — Não uso Tags, Rating, Comment, Today, Yesterday etc. no Dolphin; e desativo os serviços correspondentes
- Vários outros serviços de busca do KDE desabilitados: — Activities, Bookmarks, Browser History, Browser Tabs, Desktop Search, Dictionary, Locations, Places, Software Centre, Spell Checker, Web Search Keyords, por exemplo
- Vários Background Services desabilitados em “Startup and Shutdown” — Bluetooth, KSysguard, Plasma Vault module, Remote URL Change Notifier, Search Folder Updater, SMB Watcher (em geral, também elimino o Samba, pois não tenho rede local).
- Vários Desktop Effects desabilitados em Workspace Behavior
- Todas as distros, sem verificação automática de atualizações e sem unattended-upgrades (atualizações silenciosas de segurança) — coisas que também aumentariam o uso inicial de RAM em várias distros
- Apenas no openSUSE, serviços de manutenção BtrFS + Snapper
- Apenas no Mageia, serviço MSEC (segurança) — mas sem verificação periódica de zilhões de arquivos em todas as partições
- Apenas no Fedora, SELinux ativado. — Também veio no openSUSE, mas desabilitado
- Afora os processos normais de cada distro, estão em execução apenas 2 instâncias do Conky — a segunda, executando comandos free, top, neoFetch, htop, inxi, Screenfetch, aha, html2text (em background) a cada 10 segundos — e os widgets Weather e Moon Phase, que aumentam em cerca de 45 MiB o uso de RAM
- 2024 - No Plasma 6, tive de remover o Moon Phase (by Gealach), que ainda não foi portado; e trocar o Weather2 por outras alternativas
- Nenhum emulador de Terminal aberto — pois Konsole, XTerm, Xfce-Terminal etc. aumentam o uso de Memória, em quantidades diferentes, o que invalidaria a comparação entre distros com diferentes emuladores
- A única ação executada durante os primeiros 10 minutos uptime é a captura de tela ao exibir o Painel do KDE — pelo Spectacle (no Fedora e no Slackware); ou pelo gnome-screenshot, — ambos por comandos (background: command), sem abrir diálogo em GUI
- Aos 10 minutos uptime, um script agendado pelo crontab lê os dados em /proc/meminfo e registra o uso de Memória RAM em um arquivo TXT — usando um cálculo absolutamente igual, em todas as distros — ao contrário de ferramentas como free / top, htop, Neofetch, Screenfetch etc., que podem ter versões diferentes, com cálculos diferentes, de uma distro para outra
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
O cálculo executado por esse script (acima) é o que foi proposto por Linus Torvalds desde 2014: — Mem_Used = [Mem_Total - Mem_Available] — e que ainda não foi adotado por todas as ferramentas mais comuns.
- Naturalmente, com Xfce, LXQt, Lumina ou um simples gerenciador de janelas — em vez do Plasma KDE — todas essas distros usariam muito menos Memória RAM
GoogleEarth - Não é fornecido diretamente por nenhuma dessas distros — mas pode ser instalado e atualizado pelos gerenciadores de pacotes de várias delas, a partir do repositório do Google (ou do AUR, no Arch). — No Mageia, abre e navega normalmente, mas a Busca (cidades, ruas) não está funcionando. — No PCLinuxOS, vários usuários conseguem instalar, mas nenhuma dessas dicas resolveu para mim. — No Slackware, no Void e no Redcore, o caminho é um pouco mais complicado, e ainda não consegui, ou ainda não tentei.
Sincronização do Google - Desde quando o Google bloqueou a sincronização do Chromium (e derivados), optei pelo Chrome, instalado e atualizado do mesmo modo que o GoogleEarth — porém, no Slackware, no Void e no Redcore é mais trabalhoso — e basta não estar 100% atualizado, para não sincronizar.
Foliate - Virei fã do ePub — e como não faz sentido salvar duplicatas de tudo em PDF, me tornei dependente do Foliate, rapidamente adotado pela maioria das distros. — Só no PCLinuxOS e no Slackware, ainda não instalei.
corona-cli - Instalei pelo comando npm — mas já faz algum tempo que não uso, e fui parando de atualizar (ele notifica novas versões, mas só quando é executado). — Ainda não instalei no Slackware e no Redcore.
yt-dlp - É o sucessor do Youtube-DL, que ficou abandonado. — Fundamental para baixar vídeos, também, do Twitter, do Facebook e outros mil lugares. — É um problema no KDE Neon, cuja base Buntu-LTS fica estagnada (e eu não uso PPA, Flatpak, Snapd etc.).
speedtest-cli - Já foi uma ferramenta fantástica... até a Ookla lançar seu próprio aplicativo — e impor limitações crescentes. — Os resultados deixaram de ser confiáveis (o que me obriga a usar o site da Ookla).
Wine - Já faz alguns anos que converti a maior parte dos meus DOCs dos anos 1990, usando velhas macros que criei no MS Word — e a maior parte dos Views DXF do AutoCAD, usando o CorelDraw. — Desde o início dos anos 2000, não criei para mim nenhuma nova “dependência” desses velhos softwares, e nas distros mais recentes nem cheguei a instalar o Wine. — Pelo que verifiquei esta semana, alguma coisa daquilo tudo ainda funciona no KDE Neon e no Fedora; ao passo que no openSUSE sumiu do Menu e talvez eu precise configurar de novo.
Outros itens
 |
| Entradas para Arch e Manjaro no Grub do openSUSE e do Mageia |
Retirei do “Quadro” alguns itens que perderam importância — ou com os quais posso lidar sem necessidade de um lembrete permanente:
Grub - O Arch e o Manjaro exigem parâmetros, que só o Grub do openSUSE é capaz de detectar e incorporar, por padrão. — Para usar meu “Grub de reserva” (do Mageia), preciso fazer uma correção manual — caso a caso, conforme os Kernels do Arch e do Manjaro:
Find: initrd /boot/intel-ucode.img
Replace with / initrd /boot/intel-ucode.img /boot/initramfs-linux.img
(or) | initrd /boot/intel-ucode.img /boot/initramfs-linux-lts.img
(or) \ initrd /boot/intel-ucode.img /boot/initramfs-5.10-x86_64.img
(Se eu remover o Manjaro e 1 dos 2 Kernels do Arch, bastaria uma busca-e-troca global automática no /boot/grub2/grub.cfg do Mageia — coisa que o editor do meu Midnight-Commander (mcedit) no Mageia já está treinado para fazer).
Por outro lado, o Grub do Mageia é o único capaz de detectar e carregar o openSUSE — instalado em partição BtrFS e sem /boot em partição separada. — Por isso, é o meu “Grub de reserva”.
Nas outras 10 distros, desabilito os-prober, para que o Grub deles não perca tempo detectando outras distros. — Basta que cada um detecte e gere entradas para sua própria distro — para serem lidas e incorporadas pelo Grub do openSUSE.
(Quanto mais distros os-prober tiver de verificar, maior a demora nas atualizações de algumas distros, ao instalarem novas versões / revisões de Kernel, pois executam os-prober 2 ou 3 vezes — em especial, quando também se remove a versão mais antiga).
Por isso, faço as atualizações em ordem inversa, do último (Linux12) para o primeiro (Linux1) — para que o Grub do openSUSE detecte e incorpore as atualizações de Kernel das outras 11 distros. — Considere isso um “algoritmo” a ser seguido, ao fazer dualboot / multiboot de distros Linux.
Enfim, no Fedora precisei desativar o Boot Loader Specification (BootLoaderSpec ou BLS), que impede a geração de “entradas” no seu próprio Grub, substituídas por “entradas” em /boot/loader/entries (que o Grub de outras distros não entende). — Por isso, o dnf não atualiza o Grub do Fedora, ao instalar e remover Kernels, e preciso atualizá-lo manualmente — caso contrário, o Grub do openSUSE (ou do Mageia) não verá novas “entradas” do Fedora para atualizar.
 |
| Montagem de partições extras pelo uDisks2, via KDE System Settings |
uDisks2 - Apenas no Debian (Linux3), ainda uso o arquivo /etc/fstab para montagem automática das partições “extras” — ou seja, as que não são da própria distro, tais como “Warehouse”, “Sites”, “Works” e as partições das outras distros:
LABEL=Warehouse /media/Warehouse ext4 defaults,user 0 2
LABEL=Sites /media/Sites ext4 defaults,user 0 0
LABEL=Works /media/Works ext4 defaults,user 0 0
LABEL=Linux1 /media/Linux1 btrfs defaults,user 0 0
LABEL=Linux2 /media/Linux2 ext4 defaults,user 0 0
# LABEL=Linux3 /media/Linux3 ext4 defaults,user 0 0
LABEL=Linux4 /media/Linux4 ext4 defaults,user 0 0
LABEL=Linux5 /media/Linux5 ext4 defaults,user 0 0
LABEL=Linux6 /media/Linux6 ext4 defaults,user 0 0
LABEL=Linux7 /media/Linux7 ext4 defaults,user 0 0
LABEL=Linux8 /media/Linux8 ext4 defaults,user 0 0
LABEL=Linux9 /media/Linux9 ext4 defaults,user 0 0
LABEL=Linux10 /media/Linux10 ext4 defaults,user 0 0
LABEL=Linux11 /media/Linux11 ext4 defaults,user 0 0
LABEL=Linux12 /media/Linux12 ext4 defaults,user 0 0
LABEL=Home1 /media/Home1 xfs defaults,user 0 0
LABEL=Home2 /media/Home2 ext4 defaults,user 0 0
# LABEL=Home3 /media/Home3 ext4 defaults,user 0 0
LABEL=Home4 /media/Home4 ext4 defaults,user 0 0
LABEL=Home5 /media/Home5 ext4 defaults,user 0 0
LABEL=Home6 /media/Home6 ext4 defaults,user 0 0
LABEL=Home7 /media/Home7 ext4 defaults,user 0 0
LABEL=Home8 /media/Home8 ext4 defaults,user 0 0
LABEL=Home9 /media/Home9 ext4 defaults,user 0 0
LABEL=Home10 /media/Home10 ext4 defaults,user 0 0
LABEL=Home11 /media/Home11 ext4 defaults,user 0 0
LABEL=Home12 /media/Home12 ext4 defaults,user 0 0
Nas demais distros, uso o uDisks2 (via KDE System Settings); mas ainda enfrento falhas renitentes no Void e no Redcore, depois de reorganizar os discos (por exemplo, agora que “movi” partições dos HDDs para o novo SSD). — Isso exige montar manualmente (pelo Dolphin) as partições que faltam; e marcá-las outra vez para montagem automática.
 |
| Weather2 (widget), após o KDE 5.26 |
Weather - Uso esse widget desde 2016 (inicialmente, no KDE Neon), mas com a chegada do KDE 5.26, no último trimestre de 2022, começou a ficar truncado — exceto no MX Linux, Mageia e Slackware (ainda com KDE mais antigo). — A solução foi desinstalar o Weather (sem manutenção há 6 anos) e instalar o Weather2 (já na versão 2.33, de Outubro 2022).
 |
| Weather3 no Mageia Cauldron |
- 2025 Março - Ainda não foi portado para o Plasma 6, no KDE Store — porém, no Mageia Cauldron, apareceu um Weather3 — já instalado, porque em 2020 eu tinha instalado um pacote “plasma-applet-weather-widget”. (Também tinha instalado esse pacote no Fedora, mas não foi atualizado para “Weather3”, até agora). — Investiguei, e encontrei no AUR um pacote “plasma6-applets-weather-widget-3-git”. — Não encontrei equivalente nas outras distros.
 |
| Dados Exif das fotos no Mageia Cauldron |
Exif - No Redcore, ainda não consegui que o Dolphin mostre os dados Exif das fotos no Painel Informações (F11), do lado direito — embora o Gwenview tenha essa capacidade (ao custo de vários cliques).
 |
| Exibição de vídeos no Painel Informações (F11) do Dolphin |
Pré-visualizações no Dolphin - De um modo geral, consegui (há alguns anos) que o Dolphin mostre pré-visualizações de arquivos de imagem, de vídeo, GIFs animados, TXT, ODT, ODS, PDF, ePub, Mobi, SVG, KML KMZ, XCF, e às vezes até DOC, DOCX, CBR (com direito a assistir os vídeos no Painel) — mas sempre há exceções de alguns tipos de arquivos, em alguma distro. — Não vale a pena registrar em detalhes, até porque isso varia ao longo do tempo.
 |
| Menu de contexto do Kim4 para o Dolphin, no MX Linux |
Kim4 - Era um ótimo “menu de contexto”, desde os tempos do KDE4, para os recursos do ImageMagick no Dolphin — e ainda se encontra no AUR do Arch; e até recentemente, no repositório do MX Linux 21; enquanto o PCLinuxOS oferece um “Kim5”. — Isso deixou de ser relevante, desde que existem vários widgets com a mesma função, que podem ser baixados a partir das configurações do Dolphin.
- 2024 Dezembro - Isto se tornou um problema no Plasma 6, que ainda não resolvi.
Mudanças nos aplicativos do KDE
 |
| Antigos atalhos F10 e F11 no Kate / KWrite |
Em algum momento, Kate / KWrite perderam as antigas teclas de atalho F10, para alternar “Dynamic Word Wrap” (on / off); e F11 para “Show Line Numbers” (on / off). — O F10 pode ser restabelecido manualmente, mas F11 agora conflita com o atalho global para “Full Screen”, e preferi não mexer nisso. — A solução foi tornar padrão “Show Line Numbers” (on) nas configurações, tanto do Kate quanto do KWrite, separadamente.
(No Dolphin, F11 ainda alterna on / off o “Painel Informações”, à direita).
O Gwenview agora “não pára“ no final de uma pasta. Avança... para o começo. Se eu optar por ser avisado, preciso de pelo menos 2 cliques para voltar. — Se eu ampliar e renomear (F2) um arquivo de imagem, não volta mais ao tamanho normal (Fit); e não atualiza o nome na barra de título da janela (o que impossibilita arrastar e soltar para upload). — Para atualizar o nome e voltar ao tamanho normal (Fit), torno a usar F2 + Esc em sequência.
Essas mudanças me incomodaram, porque uso esses recursos o tempo todo, tentando não perder tempo. — Para amenizar, alterei minha personalização do Gwenview (Barra de Ferramentas). — Ainda tenho os antigos comportamentos no Slackware 15, no Mageia 8 e no MX Linux 21, mas isso está perto de acabar.
Ok, há muitos anos a evolução permanente do Plasma KDE costuma aprontar incômodos como esses (e até piores) — mas no final das contas, vale a pena, diante do acréscimo de ótimas funcionalidades. — Lembro que muitos recursos foram perdidos na passagem do KDE4 para o KDE5, e depois voltaram aos poucos.
Lidar com essas perdas faz parte da minha opção inicial pelo KDE Neon, com Plasma sempre novo; e mais tarde, por distros rolling-release — ao invés de ficar 2 anos num Kubuntu LTS estagnado, e depois receber uma cambulhada de novidades — o que anula a “produtividade”, até que eu me acostume outra vez.
O Fedora KDE Wayland alterou várias coisas. — Agora, renomear um arquivo no Gwenview (F2) abre uma sub-janela no alto, à esquerda, em vez da janelinha centralizada de todas as outras distros com a mesma versão de KWin ou dos Aplicativos KDE em sessão X11.
- Em suma, o Wayland eliminou a configuração autônoma da sub-janela pelo KWin.
Atalhos personalizados no Wayland
 |
| Criação de atalhos personalizados para o gnome-screenshot em Plasma X11 |
Há muitos anos, adotei o gnome-screenshot em “modo automático” (sem perguntas) para capturar telas ou janelas e salvar automaticamente em arquivos JPG com um padrão de nome “data + hora + sufixo da distro”:
PrtScn ----- Capture and save full screen
gnome-screenshot -p -f /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg
Shift+PrtScn ----- Capture and save full screen after 7 seconds
gnome-screenshot -p -d 7 -f /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg
CTRL+Shift+PrtScn ----- Capture and save active window
gnome-screenshot -w -p -f /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg
CTRL+PrtScn ----- Capture and save active window after 7 seconds
gnome-screenshot -w -p -d 7 -f /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg
 |
| Criação de atalhos personalizados para o KDE Spectacle em Plasma X11 |
Apenas no Slackware, eu ainda usava o KDE Spectacle, enquanto não encontro o gnome-screenshot para instalar — mas o diálogo GUI é muito incômodo, para fazer várias capturas com retardo. — Isso foi resolvido graças à dica de um colega sobre os comandos CLI, em Maio 2022:
PrtScn ----- Capture and save full screen
spectacle -p -b -o /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg
Shift+PrtScn ----- Capture and save full screen after 7 seconds
spectacle -p -d 7000 -b -o /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg
CTRL+Shift+PrtScn ----- Capture and save active window
spectacle -p -a -e -b -o /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg
CTRL+PrtScn ----- Capture and save active window after 7 seconds
spectacle -p -d 7000 -a -e -b -o /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg
 |
| Teste do KDE Spectacle por comandos no Fedora |
A discussão, naquele momento, era devido ao gnome-screenshot não funcionar em sessão Plasma Wayland — e minha primeira providência foi adotar o KDE Spectacle para poder testar o Wayland no Fedora, de modo permanente.
Logo em seguida, o KDE System Settings eliminou a seção “Atalhos Personalizados”.
- 2024 - Isto ficou ainda mais complicado, quando chegou o Plasma 6 — mas surgiu (ou demorei a descobrir?) outro caminho para criar Atalhos Personalizados, no KDE System Settings. — Ao longo do 1º semestre de 2024, também houve pelo menos 2 mudanças nos códigos do KDE Spectacle para salvar os arquivos das capturas em formato “YYYY-MM-DD_HH-mm-SS”, e quando falha o código antigo, não recebo aviso. Apenas não salva; ou salva com nome errado, e portanto fora da sequência cronológica esperada.
Gerenciadores de pacotes
 |
| Downloads do pacman em ordem decrescente de tamanho dos pacotes |
Usar vários gerenciadores de pacotes, lado a lado, todas as semanas, é uma das alegrias dessa vida — e não me canso de acompanhar os indicadores de velocidade de download, atividade de CPU, Disk I/O etc., pelo Conky.
O pacman é, sem dúvida, o mais interessante — por baixar os pacotes em ordem decrescente de tamanho, o que ajuda a manter uma velocidade ótima, já que cada requisição implica no início de uma nova remessa. — Para coroar, indica a velocidade de download de cada pacote; e a média do conjunto, no final.
O dnf, que uso só no Fedora, também tem o ótimo hábito de apresentar esses números (embora em MB, não em MiB) — mas a ordem dos pacotes é outra, o que implica em oscilações bruscas de velocidade. — E uma vez que se disponha de boa conexão, já não faz sentido o tempo gasto para calcular o “delta RPM” de cada pacote e do total de “economia de banda”.
- 2024 Outubro - O dnf abandonou essa perda de tempo com “delta RPM” . — Com o Fedora 41, o dnf5 introduziu mais algumas melhorias — mas quem preferir, ainda pode comandar “dnf4”.
Graças a essas estatísticas do pacman e do dnf, é fácil comparar a demora relativa dos downloads do zypper — sempre nos mesmos dias, com o mesmo hardware, e a mesma conexão.
A velocidade de download do zypper sempre foi apenas uma fração do que minha conexão permitia — quando eu tinha 10 “megas”, depois 200 “megas”, e agora 480 “megas”. — Contratar uma conexão mais rápida melhora, mas sempre obtenho só uma fração do obtido em outras distros, nos mesmos dias e horários.
Tanto no openSUSE quanto no Fedora, aceitei a configuração-padrão, que redireciona para espelhos mais “próximos” ou mais velozes (sem que eu saiba quais são) — mas no openSUSE o resultado é sempre muito menor. — Para comparar, no Arch eu uso um espelho fixo, ótimo no eixo Paraná-Brasília:
openSUSE Arch Fedora
4 Jun 6,6 MiB/s 33.7 MiB/s 22 MB/s
28 May 6.8 MiB/s 33,7 MiB/s 23 MB/s
21 May 10.3 MiB/s 26 MB/s
7 May ~ 5 MiB/s 19 MB/s
After "download.max_concurrent_connections = 10" in /etc/zypp/zypp.conf
18 Jun 3,3 MiB/s 29.1 MiB/s 18 MB/s
25 Jun 7.1 MiB/s 30.6 MiB/s 14 MB/s
O zypper também é menos cômodo para copiar e manter um registro em arquivo TXT (legível a partir de outras distros) — e o mesmo posso dizer do urpmi (no Mageia) e do xbps (no Void). — O urpmi não indica velocidades de download; e as velocidades que o xbps indica não conferem com o mostrado pelo “downspeed” do Conky.
 |
| Tamanho pré-definido do nala oculta listas mais extensas |
Nas distros .deb, uso o apt apenas para “ver” se todos os repositórios respondem bem — e quantos (e quais) pacotes serão atualizados. — Experimentei o nala, mas o tamanho pré-definido de seu quadro restringe a visualização de listas mais extensas (talvez possa alterar isso, mas não descobri como). — Isso é chato, no caso do Debian testing, por exemplo, que chega a consultar mais de 100 arquivos nos repositórios, para definir quantas centenas de pacotes precisa baixar.
 |
| Resumo dos pacotes e total do download, no Synaptic |
Após verificar, pelo apt, se todos os repositórios respondem, abro o Synaptic, clico em “Mark all upgrades” — e invisto um tempo a examinar as seções “Auto-removable”, “Local or obsolete”, “Residual config”, “Missing Recommended packages” etc. — Quando há nova versão ou revisão de Kernel, aproveito para procurar e marcar o mais antigo para remoção completa. — Ao clicar em “Apply”, registro o resumo dos pacotes a serem atualizados, instalados, e o tamanho do download.
Como não indica a velocidade de download, preciso medir a duração pelas capturas de tela do Conky + KRuler (1 pixel = 1 segundo) — e faço a conta. — Mas isso é trabalhoso, por isso, em geral, limito as comparações ao Pacman e ao dnf.
 |
| Pesquisa por “packagekit” no Histórico do Synaptic |
O Synaptic é uma ferramenta excepcional, com todas as funções oferecidas pelo apt (e mais nada) para examinar a consistência do sistema, os pacotes de cada repositório, e assim por diante. — Nunca encontrei nada tão completo, nem no YaST2 (openSUSE), nem no Mageia, ou em qualquer outra distro. — O histórico do Synaptic permite localizar todas as atualizações, instalações, remoções de qualquer pacote (e alguma dependência que ficou).
 |
| Synaptic do PCLinuxOS, que usa o apt-rpm |
No PCLinuxOS, não uso seus comandos apt (apt-rpm), para não me confundir com pequenas diferenças em relação ao apt das distros de base Debian — e seu Synaptic também apresenta algumas diferenças: — Se fizer 2 “Reloads” seguidos, esvazia-se a seção “New in repository”, o que é chato.
Distros “preferidas”
Já faz mais de 1 ano que uso o Arch Linux quase o tempo todo — embora eu tenha todos os recursos de que preciso, também, no openSUSE, no Debian, no Manjaro e no MX Linux. — Então, por que uso quase que só o Arch, em 99% do tempo, a semana inteira?
Talvez seja a distro que menos me dá trabalho — quase nenhum problema, nos últimos 6 anos — mas não tenho estatísticas objetivas.
Dizer que “fica fora do meu caminho”, talvez seja pouco. — “Não tem sabor, não tem cheiro, não tem cor”, talvez seja a melhor definição. — A distro ideal é aquela que eu “não percebo qual estou usando”.
O Arch é uma das mais “enxutas”, por eu mesmo ter “construído” passo-a-passo: Só tem o que eu quis instalar. — Isso o torna “mais ágil”? Talvez seja apenas outra impressão subjetiva. Sem dúvida, a ausência de pacotes inúteis ajuda a atualizar mais rápido, mas o empacotamento, o pacman, o espelho (no Brasil) e a boa conexão até minha cidade também ajudam muito.
Tudo isso também vale para o Manjaro, exceto que nele tenho 1.429 pacotes instalados, mesmo sem Wine e outras coisas (contra 1.126 no Arch, com Wine), por ser uma instalação padronizada, não-pessoal; mas a diferença mal se percebe, no dia-a-dia. Apenas, o Manjaro não me atrai. — Instalei para testar e aprender mais algumas coisas (antes de aplicá-las no Arch); e mantive como uma “reserva de segurança”. Só que não sinto medo de perder o Arch, e eu não hesitaria em remover o Manjaro, se eu quisesse experimentar mais alguma distro.
Arch Manjaro
# pacman -Q --foreign $ pamac list -m
google-chrome 114.0.5735.90-2 gnome-icon-theme 3.12.0-7 AUR 10.3 MB
google-earth-pro 7.3.6.9345-1 gnome-icon-theme-symbolic 3.12.0-6 AUR 2.0 MB
kim4 0.9.8-2 google-chrome 114.0.5735.133-1 AUR 321.6 MB
pcurses 5-5 google-earth-pro 7.3.6.9345-1 AUR 256.0 MB
ps_mem 3.14-2 manjaro-documentation-en 20181009-1 10.0 MB
yay-git 12.0.5.r9.g1335e9b-1 manjaro-firmware 20160419-1 2.6 MB
pcurses 5-5 AUR 617.3 kB
systemd-fsck-silent 239-1 34.8 kB
(+ kim4) AUR
Acima: - Além dos pacotes oficiais, tenho apenas estes, no Arch e no Manjaro.
- 2024 Agosto - Mais tarde, esse tipo de estatística se embaralhou — porque instalei uma penca de “alternativas ao Neofetch” (além de Nerd Fonts), no Arch, mas não no Manjaro. — E exagerei no Void, com centenas de Nerd Fonts, ao ponto de torná-lo uma distro entulhada, ou bloated.
O Debian testing e o MX Linux também me atendem perfeitamente — com a diferença de que o Debian traz uma quantidade enorme de pacotes que não uso (por exemplo, o LibreOffice trouxe todos os idiomas do Universo); e isso contribui para tornar mais demoradas as suas atualizações (além do seu empacotamento fragmentado). — O MX Linux desempenha as mesmas tarefas, com muito menos pacotes (2.513, contra 3.638 do Debian); e por ser “stable”, costuma ter pouquíssimas atualizações; porém, traz uma ótima coleção de aplicativos muito úteis (e em versões bem recentes), que o Debian “stable” não ofereceria.
É possível fazer uma instalação enxuta do Debian, mas não vejo motivo para tentar isso, por enquanto. — Ele me atende bem, tal como está.
Importante: - O número de pacotes do Debian / MX Linux não pode ser comparado com o do Arch / Manjaro, por se tratar de sistemas de empacotamento muito diferentes.
Outra distro que me atende perfeitamente é o openSUSE Tumbleweed — apesar de também ter um excesso de pacotes, de que não preciso, só porque aceitei os “patterns”. — Também é possível fazer uma instalação bem mais “enxuta”, mas isso é outra coisa que não me disponho a tentar, no momento: Seria muito trabalho, para pouco benefício.
Com todo possível “inchaço”, o openSUSE tem funcionado com precisão, nos últimos 6 anos e meio — através de vários upgrades de versão do Leap; e em seguida para Tumbleweed (no meu antigo PC). — Continua sólido no meu PC atual, com poucos pacotes do repositório packman-essentials (e do Google).
Tenho encontrado a mesma solidez no Fedora e no KDE Neon, através de sucessivos upgrades de versão — mas não me atendem tão completamente.
- 2024 Agosto - Tudo isso se alterou bastante, com a chegada do Plasma 6. — Hoje, é comum eu clicar para abrir algum aplicativo no openSUSE Tumbleweed, demorar a abrir, e acabar não abrindo. — E no KDE Neon com Plasma 6 (instalação nova), ainda não consegui muitas coisas que tenho na instalação antiga, com Plasma 5.
Independente de tudo isso, gosto de usar o Void, o Redcore e o Slackware.
Um passo de cada vez
Uma “regra” fundamental que tento seguir (já que tenho 12 distros em dualboot para escolher), é “não forçar a mão”, nem recorrer a soluções “fáceis” porém duvidosas, por “necessidade de urgência”. — Já que o Arch me atende do modo tão completo, posso deixar “de molho” por semanas, meses!, qualquer problema que surja nas outras distros. — Sinto-me à vontade para gastar tempo em busca de soluções “limpas”, em vez de ceder a qualquer tipo de gambiarra improvisada.
Não é, só, que eu seja um “cara enjoado” (de fato, sou). — Mas tentar fazer as coisas com calma, um passo de cada vez, ajuda muito a ter mais certeza das coisas, em vez de apenas “achar que entendi”. — Posso experimentar várias hipóteses (sem embaralhar!), uma por uma, de modo a ter razoável certeza de qual suposta solução estava errada, e de qual realmente foi a resposta certa.
O que mais evito, é tentar meia-dúzia de coisas, uma após outra (sem desfazer uma, antes de tentar outra!) — porque desse jeito, no final é impossível afirmar qual tentativa ajudou (ou impediu) que a outra desse resultado. — É fundamental testar 1 variável de cada vez, pois quando se mexe em 3 ou 10 variáveis, ninguém pode concluir nada, sobre qual delas fez diferença, por si só, ou em conjunto com (quais?) outras.
- Quando se embaralham variáveis, qualquer “conclusão” não passa de exercício do “é isso, porque minha intuição garante” — ou, pior, “é isso, porque eu sei, com base na minha sapiência”. — É melhor duvidar (sempre!) de nós mesmos, seguir um roteiro “impresso e auditável”, e apresentar todos os dados para que qualquer pessoa (contra ou a favor) tenha condições de repetir o experimento e informar à comunidade se deu certo ou não, em seu hardware, SO etc., bem especificado.
Em resumo: — Minhas conclusões podem estar erradas. — Por isso, procuro mostrar os elementos que recolhi, para qualquer colega poder verificar.
Hardware
Meu hardware ainda é o que montei em Janeiro 2020 — com alteração apenas dos dispositivos de armazenamento.
Em Maio 2023, instalei um 2º SSD de 480 GB (447 GiB) — e mais tarde desconectei os 2 HDDs de 1 TB (931 GiB) — que agora ficam em “gavetas” externas USB 3.0, para uso ocasional:
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
Local Storage: total: 894 GiB used: 251 GiB (28.1%)
Sata #1 /dev/sda SSD Sata III Kingston SA400S37480G 447 GiB probably 2019
Sata #2 /dev/sdb SSD Sata III WD WD Green 2.5 447 GiB 2022
External Storage:
USB 3.0 / 5 Gb/s HDD Sata III Seagate ST1000DM010 931 GiB probably 2021
USB 3.0 / 6 Gb/s HDD Sata III Seagate ST1000DM003 931 GiB 2016
USB 2.0 SSD USB 2.0 Samsung S2 Portable 931 GiB 2011
Quando digo “mover” partições é, na verdade, copiar & colar (pelo GParted ou pelo KDE Partition Manager) — testar as cópias — e deletar os originais.
Fiz isso de 1º a 3 Maio 2023:
- Copiei as partições Linux7 ~ Linux12 do 1º SSD (sda) para o 2º (sdb).
- Copiei as partições Home7 ~ Home12, de um HDD para sdb.
- Mudei os rótulos das partições originais para Linux7old ~ Home12old e alterei seus identificadores UUID — para testar o funcionamento das cópias em sdb, com os rótulos e UUIDs originais.
- Após testar estas 6 distros em sua nova localização, deletei as partições originais Linux7old ~ Home12old.
- Copiei as partições Home1 ~ Home6 do HDD para sda — alterei os rótulos e identificadores UUID das partições originais — e testei estas 6 distros com as cópias de suas partições /home, antes de deletar os originais.
- Copiei a partição Swap do HDD para sda. — O GParted manteve o UUID na cópia, o que dispensou alterar 12 arquivos /etc/fstab.
 |
| Renomeei as antigas partições de documentos com “_X” para preservar seus arquivos |
Três semanas depois, desconectei os 2 HDDs de 1 TB — um com 3 partições de documentos (Warehouse, Works, Sites) — e o outro, com a partição “Depot1”, onde faço os backups e guardo arquivos pouco acessados.
- Em sdb, criei uma nova partição “Warehouse”, para os documentos de uso corrente a partir de agora — e copiei só o essencial da partição antiga.
- Em sda, criei pequenas partições “Sites” e “Works” (2 GiB, cada), apenas para manter as configurações do Conky, do uDisks2, dos arquivos fstab, do rsync etc. — Ficam 140 GiB não-usados em sda.
 |
| Pastas renomeadas, para não serem esvaziadas pelos próximos backups |
Renomeei os rótulos das partições antigas para “Warehouse_X”, “Works_X”, “Sites_X” — e também seus backups em “Depot1” e “Depot2” — para não serem esvaziados, ao fazer o backup semanal das novas partições.
Observações:
- Para desmontar e lidar com as partições nº 1 ~ 6, usei uma distro do “2º grupo” (nº 7 ~ 12) — e vice-versa.
- Para copiar a partição /home do openSUSE, em sistema de arquivos XFS, usei o KDE Partition Manager do MX Linux (pois o GParted não faz isso). — A cópia já veio com um novo UUID, e tive de editar o /etc/fstab do openSUSE. — Testei 2 vezes o funcionamento do openSUSE com a sua /home em novo local, com novo UUID.
- No Slackware, uso o caminho (PATH) das partições de sistema no /etc/fstab — por isso, tive de alterar a raiz “/” para sdb2, a /home para sdb8 e o Swap para sda13. — Não é uma boa prática, pois às vezes sda e sdb podem se inverter; mas felizmente isso nunca me aconteceu com o Slackware (o mais comum é acontecer com o Redcore).
xxx
— … ≠ “•” ≠ … —
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)
Ferramentas &tc.
- Linux, dualboot, discos, partições e backups
- Adicionando HDD a 11 distros Linux em dualboot
- Ferramentas mudam o cálculo da Memória RAM usada
- Transição para hardware UEFI-GPT
- Speedtest de banda larga de “200 megas”
- Consertando pequenos problemas do Gimp 2.10
- Pré-visualização de arquivos no Dolphin
- Limpeza do Cooler da CPU
- Escolhendo Grub entre vários Linux
- Teste de memória com o Memtest86
- De volta ao Gnome-screenshot
- Konqueror como gerenciador de arquivos
- Substituição da fonte de energia do computador
- Facebook sobrecarrega visitar e compartilhar “Páginas”
- Corrigindo pontos de montagem no Linux Mint 18 KDE
- Política de Kernel do Linux Mint vs. Kubuntu, KDE Neon & Debian
- KDE “light” eliminando o PIM
- Conky - configuração em andamento
- Google Earth sem placa 3D no Xenial
- Linux ficou sem Administrador. Que fazer?
- Particionamento de disco para vários Linux
- Padronizando PrintScreen no Linux (com Shutter) e no Windows
- Montagem automática de partições adicionais (Cinnamon e Gnome)
- Boot com “Live USB” (Pendrive) do Linux Mint Cinnamon
- Repositórios de software Linux e gerenciador de pacotes Synaptic
- Monitorando a temperatura da CPU no Linux e Windows
- Conversão em massa de TIFF em JPEG
- Meu Wi-Fi parou de funcionar. E agora?
- Cópia de artigos da mídia para citação
- Lua, Júpiter e Vênus em ISO 1600
- Como se livrar do SPAM da Claro que te interrompe de 30 em 30 segundos
- Quantas pessoas cabem na Avenida Paulista?
- A batalha da Comunicação no Facebook
- O Aeroporto de Cláudio documentado no Google Earth
- O apagão do Facebook não será noticiado
- Blog, microblog e redes sociais
- Adeus ao Orkut
- Bookmark para encontrar um post “favorito” no Facebook
- Sincronização do Google Chrome
- Fotos em alta resolução no Facebook
- Sincronizando pastas de documentos entre Linux e Windows
- Dual-boot, Linux, Windows e Grub-customizer
- Listas, Grupos, Fóruns, Comunidades
- Mandar fotos por email para Grupos do Facebook
- Limitando emails de notificação do Facebook
- Conexão 3G pelo “chaveirinho” da TIM
