Byteria

domingo, 10 de setembro de 2017

Virus do Facebook está usando meu perfil. — E agora?

Se um “vírus” está usando seu Perfil, vá nas Configurações do Facebook

• Aquele velho conceito de “vírus”, — como um invasor que se instala no seu computador, — às vezes confunde usuários cujo Perfil no Facebook começa a postar coisas sem o seu conhecimento.

De repente, amigos avisam que receberam mensagens suspeitas, feitas em seu nome, e perguntam se foi mesmo você quem mandou, ou se é algum “vírus que invadiu seu computador” e você nem estava sabendo.

Conversa vai, conversa vem, amigos sugerem um “anti-vírus” X ou Y, — outros recomendam chamar um especialista, ou mandar o computador para a oficina, — ou formatar o disco-rígido, e outras coisas muito piores.

Calma. — Pode não ser bem assim.

Provavelmente, você apenas “autorizou” um Aplicativo a ter acesso à sua lista de amigos, — e a publicar ou enviar mensagens a eles, usando seu Perfil.

Essas coisas acontecem lá mesmo, — nos computadores no Facebook (não no seu), — quando você clica em um link duvidoso, provavelmente mandado pelo Perfil de outro amigo, “invadido” antes.

Trata-se de um “Aplicativo de Facebook”, — um Aplicativo feito para trabalhar com o Facebook.

Quando o Aplicativo é honesto, — por exemplo, feito para prestar serviços e facilitar sua vida, — é praxe ele (ou o Facebook) avisar que você concorda em “dar acesso aos seus dados”.

Mas quando um Aplicativo é programado para agir de má-fé, basta você clicar num link, — em geral, algum vídeo “chamativo”, com título sensacionalista, tipo “URGENTE”, pontos-de-exclamação às pencas, ─ ou mesmo um vídeo de apelo, digamos, menos angelical.

Esse tipo de armadilha nunca avisa que vai acessar seus dados, sua lista de amigos, — muito menos, que vai começar a publicar ou enviar mensagens privadas usando o seu Perfil, — sem o seu conhecimento, e sem pedir seu consentimento.

Em um mundo ideal, o Facebook deveria identificar e banir imediatamente qualquer aplicativo que se comporte desse modo, — mas, na prática, é preciso que milhares de usuários sejam vitimados, e milhares de amigos deles avisem, denunciem, e eles mesmos fiquem sabendo e reclamem, — antes que alguma coisa seja feita. Se é que algo será feito, e sabe-se lá quando.

O primeiro passo, — antes de mandar seu computador para uma clínica de desintoxicação, — é verificar quais Aplicativos estão autorizados a acessar seus dados e publicar ou mandar mensagens em nome do seu Perfil, no Facebook.

Nas Configurações do Facebook, selecione Aplicativos

Se você usa computador “de mesa”, — o chamado “desktop”, — comece pelo canto direito da barra superior (azul-tenebroso) do Facebook, e selecione a opção Configurações.

Dentro da página de Configurações do Facebook, clique em “Aplicativos”, — que está no menu do lado esquerdo da tela.

Remova qualquer Aplicativo que você não lembre de ter autorizado, nem consiga entender o que faz

Chegando à página dos Aplicativos, examine quais estão “autorizados” a acessar seus dados e usar o seu Perfil.

Qualquer Aplicativo que você não conheça, — que você não lembre de ter autorizado, nem consiga entender o que faz, — clique no “x” à direita dele, para removê-lo do seu Perfil.

Aproveite para examinar as seções “Aplicativos, sites e plugins”, “Notificações de jogos e aplicativos”, — entre outras coisas, — mais abaixo.

Você ficará surpreso de ver de quantas coisas pode se livrar, — a custo zero.

E tenha cuidado, da próxima vez que aparecer um apelo irresistível para clicar em alguma coisa. — No Facebook, a única coisa “urgente” que existe, é fazer você clicar sem pensar. — Aliás, a internet inteira é um campo fértil em “caçadores-de-cliques”.

Depois disso, sim, — cabe pensar na possibilidade de haver outras consequências. — Quem programa Aplicativos maliciosos, dificilmente deseja apenas divulgar um vídeo idiota, a troco de US$ 0,10 por exibição.

Quem trabalha de graça é relógio, — e sempre vale a pena evitar acessar seu internet-banking, ou pagar compras com cartão na internet, por exemplo, — até se certificar de que nenhum invasor foi instalado em sua máquina, “localmente”.

Infecções “locais”

Enfim, dê uma chance à ideia de usar alguma “distro” Linux, — que, volta e meia, ouço dizer que uma vez foi “invadido”, mas até hoje não consegui saber exatamente aonde, nem quando, nem como.

Não está “a salvo” de Aplicativos que trabalham, “no” Facebook, — ou seja, em máquinas remotas, distantes da sua, — mas torna desnecessário se preocupar com o “depois” (a menos que você goste de se preocupar, claro).

Para quem nunca viu “Linux”, — “nem pintado”, — recomendo Linux Mint Cinnamon, que é de longe o mais fácil, descomplicado, intuitivo, e “garantido” para computadores pessoais.

Igualmente, o Ubuntu, — que é a “base” do Linux Mint, — mas aí, você já arrisca pousar numa dúvida cruel, para novatos… Ubuntu Unity, Ubuntu Gnome, Xubuntu, Lubuntu, Ubuntu MATE…??

Pois é, o “Linux” tem essa mania chata, de te oferecer opções, — neste caso, entre diferentes “interfaces gráficas”.

Embora recomende a interface gráfica Cinnamon, — extremamente intuitiva e confortável, para quem está acostumado com Windows, — pessoalmente, prefiro a interface KDE.

Ou seja, Kubuntu, — ou Linux Mint KDE, — que têm certa “curva de aprendizado” um pouco mais extensa.

A causa disso, é que oferece possibilidades intermináveis de “personalização”, — uso há 10 anos (desde fins de 2007), e até hoje não explorei metade das possibilidades de configurar cada pequeno detalhe.

— … ≠ • ≠ … —

sábado, 2 de setembro de 2017

openSUSE Tumbleweed - instalação e configuração

openSUSE Tumbleweed instalado como devia, — sistema em partição BtrFS e /home em XFS

• xxx

— … ≠ • ≠ … —

Não-debians

sábado, 19 de agosto de 2017

Slackware Plasma 5 KDE - instalação e configuração

Slackware com Plasma 5 KDE instalado a partir da Live + Script by Alien Bob

Slackware Plasma 5 KDE instalado a partir da Live + Script by AlienBOB

A descoberta do Live Slackware Plasma 5 KDE, nas páginas do AlienBOB (Eric Hameleers), atendia meus anseios de modo tão radical, que não podia deixar de testá-lo imediatamente.

Eu já tinha instalado o Slackware 14.2 KDE “oficial”, mas estava difícil trabalhar nele uma única tarde, que fosse. — Instalar pacotes não é nada simples, para um completo novato em Slackware, — e a todo momento preciso do Chromium e do LibreOffice (entre outros), o que acabava me levando de volta às outras distros instaladas.

É verdade que “basta” aprender a lidar com repositórios & comandos, — mas para isso precisava de algum tempo, — e “tempo” pressupõe que outras atividades não sejam prejudicadas, para poder permanecer, e ir lendo, pesquisando, tentando nos intervalos.

Para maior desestímulo, o Slackware “oficial” ainda está no KDE 4, — que parece uma camisa-de-força, para quem já adaptou seu trabalho aos recursos e aplicativos do Plasma 5 KDE. — É um doloroso retrocesso.

Índice

Live Slackware Plasma
Instalação
Correção do Grub
Configurações

Adicionar Usuário

Layout de Teclado ABNT2 e Tecla de acesso ao 3º nível

Partição Swap

Beco sem saída com Auto-Login não-Plasma

Ambientes gráficos e Memória RAM

Renomeador em massa Thunar

Conclusões

Live Slackware Plasma

Live Slackware 14.2 Plasma 5 KDE, — recheado de aplicativos

Em comparação, o Live Slackware Plasma 5 KDE permitia testar a partir de um Pendrive ou DVD, — e surpreendeu pela “maciez” e estabilidade, com Chromium pronto para assistir vídeos, LibreOffice completo etc., — em um Menu 2 ou 3 vezes mais recheado do que o do Slackware “oficial”.

No mínimo, acenava com muito mais chances de encontrar pré-instalados vários outros aplicativos necessários para manter o trabalho em andamento constante, — desde o primeiro momento, — não daqui a dias ou semanas, quando tiver aprendido a lidar com repositórios & comandos de instalação.

E de fato, depois de instalar, o Localizador de Aplicativos encontra 288 (em sessão Plasma), distribuídos nas mais diversas seções.

Menu de Boot do Live Slackware Plasma 5 KDE

A imagem ISO tem 4,2 GiB. — Foi baixada em 17 Ago., checado por md5sum e gravado pelo K3b em DVD (para guardar).

17:34 - Os primeiros passos, a partir do Menu de Boot, foram a escolha do layout de Teclado e do Idioma.

17:41 - Na tela de Login, — marcando “20:41” (UTC), — foram gastos 5 minutos até adivinhar a senha de Usuário (live). Acho que só eu não sabia ;-)

Daí, até cerca de 20:21, o relógio do Painel marcou sempre horário UTC, — e várias tentativas de Sincronização resultaram em mensagens de erro (“Não foi possível etc.”). — Só a partir de 20:34, as imagens começam a mostrar a hora correta no Painel, mas não há registro de como isso aconteceu.

Scripts de instalação do Live Slackware 14.2 Plasma 5 KDE em Pendrive e HDD

Não encontrei “Instalar” na tela, nem no Menu, e após alguma pesquisa me preparava para rodar o script “iso2usb”, — com direito a “persistência”, para guardar arquivos e configurações de uma sessão Live Pendrive para outra, — quando me deparei com outro script, chamado “setup2hd”, do qual ainda não tinha visto nenhuma citação, nem orientações.

Clonando a partição do Slackware “oficial” para a unidade externa SSD

Já tinha notado o GParted no Menu, — portanto, bastou clonar a partição (sdc2) do Slackware 14.2 KDE “oficial”, instalado no mês anterior, para uma partição vazia (sdd3) da unidade externa SSD.

Se a nova experiência não desse certo, bastava clonar o Slackware “oficial” de volta para o HDD interno.

Localização dos sistemas Linux, após a instalação do Slackware Plasma 5 KDE

Mas, se tudo desse certo, com certeza iria usar o Slackware Plasma 5 KDE por vários dias seguidos, — sem ter de manter o SSD plugado esse tempo todo. — E de fato, hoje (25 Ago.) fazem 8 dias que praticamente não uso outra distro.

O trabalho flui sem atrasos nem percalços. — Só precisei sair alguns minutos, para usar o pyRenamer instalado em outra distro, — a fim de corrigir uma burrada minha com o "renomeador em massa” do Thunar.

Adicionando aba “Camadas” à caixa de ferramentas do Gimp, após fechar a da direita para ganhar espaço

Enfim, o registro visual da instalação merecia um Wallpaper decente, — e para mergulhar numa fria, nada melhor do que uma coalhada de nuvens da Frente fria fotografada ao amanhecer de 18 Mai. 2015.

Alteração do Compositor para conseguir efeitos de transparência na sessão Live de instalação

Para conseguir os efeitos de transparência aplicados pelo Kwin, — sem placa aceleradora 3D (vídeo onboard, 256 MB subtraídos da RAM), — foi necessário trocar o Compositor OpenGL 2.0 pelo XRender.

Live Slackware Plasma 5, pronto para iniciar a instalação

Foram obtidos e aplicados o tema Maia Transparent, — originário do Manjaro, com seu ícone característico no lugar do Menu K, — e a decoração de janelas Transparent Oxygen.

Na falta do Conky, foi usado o KSysguard, — apesar das dúvidas sobre sua indicação de uso de Memória RAM, — para monitorar as atividades de CPU e de Rede.

Instalação

Menu inicial do script de instalação do Live Slackware Plasma 5

A instalação começou às 21:17, — já com a hora local no relógio do Painel, — e se concluiu às 23:17, com duração exata de 2 horas, incluindo as configurações post-install.

Para essa demora deve ter contribuído a opção por DVD, com baixa taxa de transferência, — e o grande volume de pacotes instalados, — nada menos que 14,4 GiB de espaço usado na partição do sistema, contra 9,55 GiB usados pelo Slackware “oficial”.

Não foi observada atividade de Rede (web), — portanto, a velocidade da conexão não parece ter influído em nada.

Opções de formatação da partição de sistema do Live Slackware Plasma 5 KDE

Logo de início, quis “ver” a etapa Target, — para me certificar de que poderia formatar a partição de destino, e com qual ferramenta, qual o formato recomendado etc., — mas acabei me entusiasmando e segui em frente, sem lembrar que havia pulado as etapas Keymap e AddSwap.

Felizmente, falta de Swap e de Keymap personalizado não mata, — “bastou” resolver isso mais tarde, com o sistema já instalado e funcionando.

As opções são bastante simples, — formatação rápida, ou com verificação, ou não formatar, — sem direito a deletar, criar ou redimensionar partições. As alternativas de formato são dadas mais ou menos por ordem cronológica de surgimento, sem nenhuma indicação de preferência.

Talvez tenha imaginado que voltaria ao Menu inicial do Script e poderia rever etapas anteriores, — como na fase de seleção dos pacotes a serem instalados no Arch, por exemplo, — mas isso não acontece.

O Menu inicial da instalação nunca mais voltou a aparecer, — como se servisse apenas dar uma ideia das etapas… ou para alguém começar pela metade ;-) — Acho que o caminho era clicar em “Cancel” e, se necessário, recomeçar.

Na sequência, foi oferecido escolher outras partições a serem montadas pelo /etc/fstab, — escolhi a /home (sdc6), e “não formatar”. — Mais tarde, fui surpreendido pelo Wallpaper e configurações herdadas do Manjaro KDE, pois o Slackware “oficial” não tinha recomendado partição /home separada, e a “Home8” continuava intacta.

A listagem das Capturas de tela, — nomeadas por data e horário, — é um bom roteiro dos passos percorridos e das opções feitas ao longo do processo:

21:17 - Instalar
21:21 - Format sdc2 (Linux8)
21:21 - Type: ext4 — usar como partição-raiz (“/”)
21:22 - Select sdc6 (Home8)
21:22 - Format? - No
21:22 - Mountpoint - /home
21:24 - Partições Swap indisponíveis nesse ponto
21:25 - Resumo do Fstab (sem Swap)
21:26 - Calcula o espaço
21:26 - Espaço suficiente, Ok
21:26 - Processing modules
21:35 - 6%
21:59 - 34% - Conferindo que Teclado ABNT2 estava Ok na sessão Live.
22:13 - 50%
22:15 - 53% - KSysguard - Processos ordenados por Memoria
22:16 - 53% - KSysguard - Processos ordenados por CPU
22:54 - 96%
22:57 - Copy Live modifications to HDD

Dicas e sugestões para o pós-instalação do Live Slackware 14.2 Plasma 5 KDE

As modificações da sesão Live a serem copiadas para o HDD incluiriam Keyboard layout e Language settings, — que estavam bem configurados e funcionando muito bem, — porém devem ter ido para a pasta /root (a “home” do Superusuário), uma vez que não foi criada nenhuma conta de Usuário comum.

Descartei a oferta de instalar mais alguns “módulos”, — dos 4 não-instalados por default. — De fato, não cheguei a examinar quais eram, nem como fazer.

22:57 - Post-install
23:00 - Dica: — “Run fc-cache whenever fonts are added to system”
23:05 - Create bootable Pendrive - Yes — (ainda sem uso, após 8 dias)
23:07 - Skip Lilo
23:08 - Mouse
23:09 - Network config
23:09 - Hostname - “Linux8”
23:10 - Domain name (inventado, senão não ia)
23:11 - DHCP
23:12 - Confirm Setup
23:12 - Startup Services
23:13 - Console font configuration - Try out some custom screen fonts? - No
23:14 - Hardware clock set to UTC? - Yes
23:14 - Fuso horário

Default window manager for X, — imagino que ainda possa ser alterado, para testes

23:15 - Select window manager for X - Troquei Xfce por Plasma
23:16 - Root password
23:17 - Instalação completada - Restart

De um modo geral, acredito não ter alterado mais nada, do que foi sugerido para o Mouse, DHCP, Startup services etc., — mas me baseio na frágil suposição de que “teria documentado”, caso mexesse em mais alguma coisa. — Distrações acontecem.

Documentando a etapa de escolha da partição Swap do Live Slackware Plasma 5 KDE

Apenas para documentar, reiniciei o Script de instalação, — conferi como teria sido a escolha do Swap, — mas interrompi, sem ir adiante:

23:17 - AddSwap
23:18 - Achado sdc10 — definida a entrada a ser adicionada em /etc/fstab
23:19 - Ctrl-C - Abortar

No mínimo, ficou documentada a linha que seria adicionada ao /etc/fstab:

/dev/sdc10 swap swap defaults 0 0

Correção do Grub

Correção manual do Grub para carregar o Slackware sem “end trace”

Descartei instalar o Lilo, — e após 8 dias ainda não precisei do Pendrive de Boot, — devido à intenção de manter o Grub gerenciado pelo Mageia (boot a partir da MBR do sda) e, por precaução, outro gerenciado pelo openSUSE (boot pela MBR do sdb).

À 23:36, foi carregado o Mageia para atualizar o Grub, — incluir o Slackware Plasma 5 KDE (sdc2) e a nova localização do Slackware 14.2 KDE “oficial” (sdd3), — porém o carregamento de ambos foi abortado com a famigerada mensagem “end trace”.

No próprio Menu de Boot, foi teclado “e” para Editar, — mudar “vmlinuz-generic-4.9.37” para “vmlinuz-huge-4.9.37”, em seguida “Ctrl-X” para executar o Boot conforme editado, — e finalmente consegui chegar à tela de Login do Slackware 14.2 Plasma 5 KDE.

Tela de Login do primeiro Boot do Slackware 14.2 Plasma 5 KDE instalado

Duas surpresas, — que um usuário perfeito teria previsto:

1) Tive de logar como Root, — uma vez que não havia criado nenhum Usuário, nem outra senha.

2) Carregou uma sessão Lumina, — como poderia adivinhar, se prestasse atenção no canto inferior esquerdo da tela.

Configurações

As configurações básicas não apresentaram novidades, — aliás, a maioria foi automaticamente “herdada” com a “Home8” do Manjaro KDE, numa proporção surpreendente, — e mais vale registrar os itens que fugiram do comum:

18 Ago., 1:43 - Adicionar Usuário

Adiado - Adicionar Usuário ao sudoers
18 Ago., 20:29 - Layout de Teclado ABNT2
19 Ago., 0:36 - Tecla de acesso ao 3º nível
20 Ago., 12:59 - Partição Swap
21 Ago., 21:42 - Beco sem saída com Auto-Login não-Plasma

Pendente - Montagem automática de partições adicionais

Adicionar Usuário

Primeira sessão não-Root, — já com Wallpaper, Tema e Decoração de janelas do antigo Manjaro KDE

18 Ago., 1:43 - Adicionar um Usuário comum foi uma das primeiras providências, me limitando a aceitando os defaults, — com exceção da pasta, que já existia, mas optei por não renomear (para criar outra em branco).

Portanto, não foi copiado o conteúdo-padrão de /etc/skel para novos usuários. — Apenas, a propriedade foi transferida:

bash-4.4# adduser flavio
…
- Warning: '/home/flavio' already exists !
Do you wish to change the home directory path ? (Y/n) n
Do you want to chown flavio.users /home/flavio ? (y/N) y

Not copying any file from skel directory into it.

Uma consequência dessa decisão é que, — ao carregar a primeira sessão com Login do Usuário comum, — o novo Slackware Plasma 5 KDE já exibiu as configurações herdadas do Manjaro KDE, incluídos Wallpaper, Tema Maia Transparent, Decoração de janelas Transparent Oxygen, Menu K alternativo em Cascata etc.

O preço a pagar por isso foi abrir mão da moleza, — que seria receber tudo já configurado de acordo com a estrutura do Slackware.

O uso do sudo parece não ser recomendado, e ficou adiado por enquanto.

Teclado ABNT2 e Tecla de acesso ao 3º nível

Pela primeira vez, deu trabalho configurar Teclado ABNT2 com acesso ao Terceiro nível

18 Ago., 20:29 ~ 23:36 - Pela primeira vez, — em 2 anos instalando as mais variadas distros, — vi as “Configurações do sistema” (KDE System Settings) se mostrarem incapazes de fazer funcionar o layout de Teclado ABNT2.

Compreensível, já que nunca instalei um Slackware sem configurar Local / Idioma, para tentar usar uma /home que era de outra distro. — Também nunca tive de criar o Usuário depois da instalação, — nem deparar uma situação em que um mínimo de configurações da nova distro / nova versão não fosse sobre-gravado na /home preexistente.

Consegui criar um monstrengo.

Algumas horas de pesquisa e experimentação acabaram resolvendo o assunto, — pela edição de arquivos de configuração, aqui e ali, — mas convém registrar esses passos, para facilitar eventuais correções no futuro.

As páginas consultadas vão indicadas no final, em “Referências”.

Editando /etc/profile.d/lang.sh

23:14 ~ 23:31 - Edição dos arquivos “/etc/profile.d/lang.sh” e “/etc/profile.d/lang.csh”, — após pesquisar as opções disponíveis, pelo comando “locale -a”, conforme sugerido nos próprios arquivos. — Como a lista é extensa, filtrar “pt” facilita a pesquisa:

root@Linux8:~# locale -a | grep pt
pt_BR
pt_BR.utf8
pt_PT
pt_PT.utf8
pt_PT@euro

Também filtrei por “br”, mas os resultados se referem ao idioma Bretão, na França (br_FR); e Bodo, na Índia (brx_IN).

No arquivo /etc/profile.d/lang.sh, a linha editada ficou assim:

export LANG=pt_BR.utf8

No arquivo /etc/profile.d/lang.csh, a linha editada ficou assim:

setenv LANG pt_BR.utf8

22:02 ~ 23:36 - Edição do arquivo /etc/X11/xorg.conf.d/90-keyboard-layout.conf, — que teve de ser copiado de outra pasta do sistema, conforme sugerido na Referência nº 1:

cp /usr/share/X11/xorg.conf.d/90-keyboard-layout.conf /etc/X11/xorg.conf.d/

Na verdade, o arquivo de origem não foi encontrado com esse nome exato, — o que existe lá são 2 arquivos com nomes diferenciados, — e com a mesma estrutura, exceto pelo driver:

[flavio@Linux8]: /usr/share/X11/xorg.conf.d>$ ls -1 *keyboard*
90-keyboard-layout-evdev.conf
91-keyboard-layout-libinput.conf

A versão copiada foi “90-keyboard-layout~~-evdev~~.conf”, — eliminando “edev”.

Após várias tentativas, ficou claro que não adianta usar “pt / br”, nem “pt / abnt2”, nesse arquivo.

A dupla que de fato funciona, — encontrada na Referência nº 3, — é “br / abnt2”:

Section "InputClass"
Identifier "keyboard-all"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "XkbLayout" "br"
Option "XkbVariant" "abnt2"
Option "XkbOptions" "lv3:lwin_switch,terminate:ctrl_alt_bksp"
EndSection

23:36 ~ 0:36 - Ainda faltava ativar a Tecla de acesso ao 3º Nível, e a busca prosseguiu até descobrir a opção “lv3:lwin_switch”, — em /usr/share/X11/xkb/rules/base.lst, — citado na Referência nº 4 e no rodapé da Referência nº 2:

[flavio@Linux8]: ~>$ cat /usr/share/X11/xkb/rules/base.lst
…
lv3:lwin_switch Left Win
…

23 Ago. 2017, às 20:25 - Dias depois, ao levantar todos esses passos para consolidar o relato, notei que ainda não existia o arquivo /etc/rc.d/rc.keymap, citado na Referência nº 1, — e de fato não havia acentuação fora do ambiente gráfico:

#!/bin/sh
# Load the keyboard map. More maps are in /usr/share/kbd/keymaps.
if [ -x /usr/bin/loadkeys ]; then
/usr/bin/loadkeys uk.map
fi

Situação normal, dado que durante a instalação não foi escolhido um idioma diferente do padrão:

Please note that if you decide not to change the default layout (US) during the installation process, the file /etc/rc.d/rc.keymap will not be created. If, at a later stage, you need to change it, you will need to create that file, copy the above code and choose one of the keymaps available in the /usr/share/kdb/keymaps/ directory.

[flavio@Linux8]: /usr/share/kbd/keymaps>$ ls -R | grep 'pt'
pt-olpc.map.gz
pt-latin1.map.gz
pt-latin9.map.gz
pt.map.gz
mac-pt-latin1.map.gz

[flavio@Linux8]: /usr/share/kbd/keymaps>$ ls -R | grep 'br'
br-abnt.map.gz
br-abnt2.map.gz
br-latin1-abnt2.map.gz
br-latin1-us.map.gz

Em vez disso, primeiro tentei um simples comando, experimentando diferentes opções, — e o parâmetro “br” habilitou acentuação no Terminal, — mas apenas dentro da interface gráfica (GUI):

root@Linux8:~# setxkbmap br
root@Linux8:~# ção é êpa

O arquivo /etc/rc.d/rc.keymap continuou inexistente, — e fora da interface gráfica o tty continuou sem acentuação, — mas dentro da sessão Plasma 5 KDE o Terminal continua acentuando (com direito aos caracteres especiais do 3º Nível), mesmo após 2 reinicializações do computador.

root@Linux8:~# echo ─ © → ↓ ↑ ← m³ km²
─ © → ↓ ↑ ← m³ km²

24 Ago. 2017 - Copiei o arquivo /etc/rc.d/rc.keymap do outro Slackware, — com a linha “/usr/bin/loadkeys br-abnt2.map”, — e ao reiniciar o computador a acentuação funcionou no tty, — mas não as setas, nem as teclas Home e End. O arquivo foi apenas renomeado para “rc_keymap.txt” e, ao reiniciar, o tty voltou ao “normal”, — sem acentuação, mas com as setas, Home, End funcionando corretamente.

No dia 18, no início das pesquisas, editei o arquivo /etc/profile.d/gtk+.sh, — acrescentando uma linha “export GDK_IM_MODULE=xim”, — porém não guardei backup do original. Agora, trouxe uma cópia “original” do outro Slackware.

Feitas as contas, o Teclado ABNT2 funciona a contento (com acesso ao 3º Nível), em todos os aplicativos do Plasma 5 KDE, — e ainda não encontrei nenhum comando que precise de acentuação no tty. — Entre mortos e feridos, salvaram-se todos.

Referências:

Beco sem saída

Edição do /etc/sddm.conf para conseguir sair do Lumina

Uma experiência besta, — alterar nas “Configurações do sistema” (KDE System settings) a sessão-padrão para “Lumina”, — me deixou numa sinuca-de-bico, uma vez que deixei configurado “Login automático” e “Entrar novamente após sair”.

São opções que adotei em todos os sistemas, — já que a maioria tem apenas KDE (exceto Mageia KDE, que também tem IceWM), — mas inadequadas neste caso.

Uma vez dentro do Lumina, o “KDE System settings”, — disponível, também lá, — até fingia aceitar a mudança da sessão-padrão para “Plasma”, mas… não “colava”. Bastava andar para lá e para cá, e na volta estava tudo como antes. Sessão-padrão “Lumina”.

O mais complicado foi tentar descobrir qual Display Manager estava em uso, e qual o seu arquivo de configuração, — coisa banal, depois que a gente já sabe tudo. — O comando “whereis” salvou o dia:

root@Linux8:~# whereis lxdm
lxdm:
root@Linux8:~# whereis gdm
gdm: /usr/share/gdm
/usr/share/sddm
root@Linux8:~# whereis kdm
kdm: /usr/share/kdm
root@Linux8:~# whereis sddm
sddm: /usr/bin/sddm.bin /usr/bin/sddm /etc/sddm.conf

Tratava-se do sddm, e sua configuração estava em /etc/sddm.conf.

Ambientes gráficos e Memória RAM

Além do Plasma 5 KDE, — com as opções Failsafe e Wayland, ainda não experimentadas, — essa instalação do Slackware 14.2 também trouxe outras interfaces opcionais.

Até o momento, fiz apenas algumas medidas do uso inicial de Memória RAM, — um tanto desiguais, na medida em que algumas “chamam” um Terminal diferente, para rodar automaticamente o htop ao iniciar a sessão. — Em outras, tenho de abrir manualmente um Terminal, e neste caso prefiro o XTerm.

Além do Konsole, a instalação inclui QTerminal, QTerminal suspenso, UXTerm, XTerm e Xfce Terminal, — porém no Openbox um deles (com outro nome) não funcionou, por enquanto.

Entre as opções de Captura de tela, estão o “Captura de tela” (xfce-screenshooter), Lumina Screenshot (lumina-screenshot), Captura de ecrã (lximage-qt), e o KDE Spectacle, — com diferentes graus de interferência no uso da Memória RAM.

Enfim, configurações “herdadas” de outras distros, via “Home8”, também podem ter interferido no uso inicial de Memória RAM.

Plasma 5 KDE - Uso inicial de 400 ~ 440 MiB de Memória RAM, — com frequência, 402 ~ 412 MiB. — A menor marca flagrada pelo KDE Spectacle (que às vezes altera esse valor, antes mesmo de capturar a tela) é 397 MiB, — incluído Konsole + htop.

Lembrando que é o único ambiente gráfico configurado (aliás, bastante configurado), — com Wallpaper um pouco mais pesado (1,9 MiB), — mas também com desativação da “Pesquisa de arquivos”, entre outros serviços. A tabela de processos do KSysguard indica que não está em atividade nenhum item do KDE-PIM, Baloo ou Akonadi.

Naturalmente, todos esses valores foram tomados de 30’’ a 1’30’’ após o pico inicial, — quando o uso de Memória RAM decai e se estabiliza, na ausência de outras ações do usuário.

Slackware 14.2 by AlienBOB em sessão Lumina

Lumina - Uso inicial de 238 MiB de Memória RAM. — Menu recheado de aplicativos, inclusive o KDE System settings, — porém não altera coisas como a tela de autenticação SDDM, mesmo com a senha de Root.

Slackware 14.2 by AlienBOB em sessão Xfce

Xfce - Uso inicial de 281 ~ 302 MiB de Memória RAM. — O Painel inferior está inativo e pode ser “herança” de outra distro anterior, via “Home8”.

Slackware 14.2 by AlienBOB em sessão LXQt-Openbox

LXQt-Openbox - Uso inicial de 236 MiB de Memória RAM. — Menu recheado de aplicativos.

Slackware 14.2 by AlienBOB em sessão Openbox

Openbox - Uso inicial de 99 ~ 104 MiB de Memória RAM, e poucos aplicativos no Menu (right-click), — nenhum capturador de tela, nem Chromium, por exemplo.

Renomeador em massa do Thunar

Renomeador em massa do Thunar erra a hora em que as fotos foram tiradas

Nem só de Plasma 5 KDE vive o Live Slackware, — e se você digita “KRename” no Menu ele oferece “Renomear em massa”, você fica feliz da vida, — mas o que se abre é o do Thunar.

Tentei usá-lo, — deu algum trabalho, aprender coisas diferentes, — e parecia ter tido pleno sucesso, até perceber que a hora de algumas fotos não batia com a dos demais registros.

Por algum motivo, as fotos foram renomeadas para 1 hora antes.

Renomeador em massa do Thunar acerta a hora em que o arquivo foi “modificado”

Mais tarde, verifiquei que poderia usar a hora em que o arquivo (foto) foi “modificado”, — aí, sim, tudo funciona como devia.

Conclusões

Quadro comparativo do desempenho obtido até o momento com diferentes distros Linux

Eu não tinha o menor conhecimento da distro, até o mês passado, quando instalei o Slackware 14.2 KDE “oficial”, — que, ao cabo de 1 mês, mal tinha conseguido usar por 2 ou 3 dias inteiros, — ao passo que hoje (25 Ago. 2017) se completam 8 dias de trabalho mais do que produtivo no Slackware 14.2 Plasma 5 KDE “by AlienBOB”, instalado de modo incompleto (sem ler quase nada), e com decisões pouco recomendáveis (uma /home que não era dele).

Nesses 8 dias, lembro de 2 ou 3 crashes, — um deles, ao configurar o Konqueror, já registrado várias vezes no KDE Neon, e algumas vezes também em outras distros.

Penso que isso diz muito sobre a estabilidade e consistência do Slackware, do trabalho de implementação do Plasma 5 KDE, — expurgado do systemd, — e do script de instalação setup2hd.

Dito isso, cabe notar que esses 8 dias não foram de trabalho confortável, — foi praticamente impossível percorrer, 2 ou 3 vezes por dia, uma dúzia de “Páginas” do Facebook (não Feed, Grupos, Perfis) que considero fundamentais para me manter informado. — Impossível, também, navegar em alguns portais de notícias como o Estadão, DCM, 24/7 (entre outros), entupidos de anúncios intrusivos, sem despoletar um surto de uso (abuso) de CPU, que deixa tudo muito devagar, quase travando. Mas isso também acontece no Debian (há anos), no Devuan e no Arch Linux, afora outras distros já desinstaladas.

A última coisa que pretendo tentar, por enquanto, é instalar pacotes adicionais, — pois o pouco que penso ter conseguido entender recomenda muita leitura e cautela.

_____________________
Publicado inicialmente às 2:56 de 19 Ago. 2017, e desenvolvido até 25 Ago. 2017, no Slackware 14.2 Plasma 5 KDE instalado.
• As datas e horas são citadas, a cada passo, para facilitar a revisão de Fotos, Capturas de tela, Comandos e Anotações, caso venha a ser necessário no futuro.

— … ≠ • ≠ … —

Não-debians

quarta-feira, 16 de agosto de 2017

Slackware - instalação e aprendizado

Slackware 14.2 com Kernel 4.4 e KDE4

O Slackware 14.2 KDE foi instalado em 14 Jul. 2017, mas permaneceu quase sem uso por mais de 30 dias.

Veio sem LibreOffice (só Calligra), afora outros aplicativos que é normal não virem, — e instalar novos pacotes exige mais do que um “aprendizado rápido”. — Era difícil trabalhar nele e, portanto, difícil permanecer muito tempo.

Em 11 horas de trabalho, hoje, o que mais fez falta foi o KRename, pois sua versão do KSnapshot (KDE4) nomeia as Capturas de tela por mera numeração sequencial.

Usar KSnapshot já não é coisa banal, hoje em dia, — acionar 3 teclas, em extremidades diagonalmente opostas do teclado, passando por 1 clique do mouse num ponto exato da tela. — Talvez por isso, o número de Capturas está baixo (e muitos detalhes ficaram sem documentar).

Seria prudente tentar compensar com anotações no Caderno, — mas teria levado o dobro do tempo. — Escrever à mão é extremamente ineficaz.

A falta do Chromium também complicou o trabalho, — foi necessário exportar seus Bookmarks e importá-los no Firefox, semanas atrás, — mas isso teria de ser repetido a cada dia (nos 2 sentidos). Não é prático.

Estado do sistema ao concluir a primeira parte do relato

Afinal, encontrei tempo para investir no Slackware, — e os primeiros resultados recomendavam começar logo o registro das tentativas, — pois fogem ao que estou acostumado a fazer (e lembrar).

Por isso, a prioridade são essas últimas tentativas, — já que a instalação inicial e as primeiras configurações foram relativamente comuns.

O objetivo não é ensinar nada a ninguém, — muito menos, simular conhecimentos, — mas deixar um registro que permita, no futuro, entender a origem de prováveis erros, para corrigir.

Antes tarde do que nunca

“slackpkg install d” para obter os compiladores, desprezados ao instalar o Slackware

O hábito de preferir informações mais recentes, — ou, mesmo, limitar as buscas ao último ano, — me privou de um ótimo tutorial e dos sábios conselhos oferecidos por Carlos E. Morimoto há mais de 10 anos.

Perderia bem menos tempo na instalação do Slackware, — selecionando logo todas as categorias (exceto Xfce), — e em seguida o modo “Full - Install everything”:

«Além de não ter a preocupação de ter de ficar imaginando quais pacotes você precisa ou não (acredite, nem quem trabalha diariamente com Linux conhece a função de todos os pacotes incluídos em uma distribuição atual), você vai ter uma facilidade muito maior em usar o sistema e, principalmente, instalar novos programas, pois todas as bibliotecas e outros componentes eventualmente necessários já estarão à mão» [Seleção dos pacotes].

Essa burrice ficou evidente ao pesquisar “Repositórios adicionais”, — para procurar coisas como Conky, Chromium, LibreOffice, KRename, — e me dar conta de que tudo isso vai depender de uma variedade de ferramentas de compilação, sobre as quais não faço a menor ideia.

Ok, parece que não sou eu quem terá de lidar com elas, — o processo é bastante automático, — mas as ferramentas (sejam quais forem) devem estar presentes.

Para isso, a melhor solução foi o comando “slackpkg install d”, — que instala tudo dessa “categoria”, de uma vez só, — a menos que você queira perder tempo escolhendo.

Atualização inicial

“slackpkg upgrade patches”

Primeiro, algumas providências preliminares, — acredito que atualizei as informações dos repositórios, instalei as atualizações disponíveis (patches) e, por fim, instalei algumas novidades surgidas nos repositórios (new).

Aproveitei para reinstalar o Gwenview, que sempre abortava ao tentar abrir uma Captura de tela, — mas não sei se foi isso que resolveu. — No final, abriu pelo Menu, e só depois disso passou a abrir (também) clicando nas imagens.

Antes, ainda, ir nas “Configurações do sistema → Associações de arquivos” e padronizar BMP, GIF, JPEG, PNG, TIFF, — colocando sempre Gwenview no topo e Gimp logo em seguida.

Levantamento retrospectivo a partir do histórico de comandos fornecido pelo comando “history”, — aqui expurgado do que era irrelevante:

53 # slackpkg update gpg
54 # slackpkg update
66 # slackpkg upgrade patches
70 # slackpkg reinstall gwenview-4.14.3-x86_64-2
74 # slackpkg install-new
80 # slackpkg install d

Datando os comandos

Início da datação dos comandos no “/.bash_history”

Depois de perder tempo tentando identificar pelas Capturas de tela o possível horário de cada comando, — fornecido pelo “history” apenas com a numeração sequencial, — deixei tudo de lado e fui caçar um jeito de datá-los automaticamente.

É um problema que já tomou muito tempo, em várias ocasiões. — Agora, a solução será aplicada nos demais sistemas já instalados, — bem como nos próximos:

2017-08-16_18:56:36 $ / # echo 'export HISTTIMEFORMAT="%F_%T "' >> ~/.bashrc
2017-08-16_18:56:38 $ / # source ~/.bash_profile

Ao que parece, o primeiro comando já faz essa configuração, — pois o segundo costuma retornar erro, — e mesmo assim, a datação passou a funcionar.

Foram usados, primeiro, como Usuário ($), — e depois, como Superusuário (#), — pois cada um tem seu próprio “/.bashrc” (achava eu), nas pastas “/home” e “/root”.

Infelizmente, só passou a preservar a data dos comandos executados daí por diante, — os anteriores serão sempre exibidos com o horário “atual”, a cada vez que disparar um comando “history”. — Portanto, o ideal é aplicar essa configuração o quanto antes. Se possível, logo após a instalação de cada nova distro.

Mais tarde, o formato de “hora-minuto-segundo” foi desmembrado, para substituir dois-pontos (colon) por traço, — padrão já adotado no nome-de-arquivo das Capturas de tela das demais distros:

echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc

Deletando o excesso de parâmetros (contraditórios) no “/.bashrc”

Naturalmente, a repetição de comandos “echo” seguidos de “>>”, — que acrescenta a resposta ao final de um arquivo já existente, — deixou diferentes versões no “/.bashrc”.

Ao que parece, vale o último, — mas não custava nada apagar os anteriores. — Para isso, o arquivo foi localizado no Midnight Commander (mc) e editado (F4) rapidamente.

“slackpkg reinstall kdei” para reinstalar os pacotes de idioma do KDE

Também pedi a reinstalação da categoria “KDEI”, — idiomas ou internacional, — e selecionei os pacotes de Português (pt) e Português do Brasil (pt_BR):

116 2017-08-16_20:06:22 # slackpkg reinstall kdei

Até agora, nenhuma certeza de que essas coisas tenham sido feitas corretamente, — por isso, é bom registrar logo (enquanto lembro bem), para exame posterior.

Instalação do Slackware

Em breve.

Epílogo

A experiência acabou dando lugar a outras 2 de resultados mais promissores a curto prazo

A produção deste relato foi interrompida em 17 Ago. 2017, para a instalação do Live Slackware Plasma 5 KDE, by Alien Bob, — que atende fantasticamente às minhas necessidades de trabalho diário, — e por isso, talvez demore um pouco a retomar.

Nesse dia, suas partições (Linux8, Home8) foram clonadas para a unidade SSD externa (Linux12, Home12), — para dar lugar ao Live Slackware Plasma 5 KDE, — e não voltou mais a carregar, em seu novo local, embora essa operação de clonagem já tenha funcionado várias vezes, tanto antes quanto depois disso.

Em 2 Set. 2017, as partições Linux12, Home12 foram sobregravadas com o clone do Devuan, — para dar lugar à instalação do openSUSE Tumbleweed em Linux6, Home6. — O Devuan carregou normalmente (após ajustes no /etc/fstab), e seu Kernel foi reinstalado, para consolidar sua nova localização. Ver “Remanejamento de sistemas Linux ao reparticionar discos”.

_________
Inicialmente publicado em 16 Ago. 2017, no Slackware 14.2 KDE, para desenvolvimento nos próximos dias e semanas.

— … ≠ • ≠ … —

Não-debians

quarta-feira, 2 de agosto de 2017

openSUSE - removendo Snapper, PIM, Baloo e Akonadi

Deletando manualmente snapshots que proliferam como coelhos no openSUSE. — Nem sinal do nº 258

• Este relato documenta:

1) A remoção do máximo dos pacotes que compõem o KDE-PIM, Baloo e Akonadi, — tal como “vieram”, automaticamente instalados com o openSUSE Leap 42.2 KDE, — exceto os necessários ao funcionamento de outros aplicativos, ou do sistema como um todo (“dependências”); e

2) A remoção / configuração “mínima (necessária)” para desabilitar o funcionamento do Snapper, — cuja função é gerar sucessivos “instantâneos” (snapshots) do Sistema, que permitem reverter (roll-back) passos “infelizes”, causados por atualizações, instalação de novos pacotes etc.

Mas o mais importante é que este relato documenta o “caminho de volta”, — para o caso de querer desfazer uma dessas 2 decisões.

KDE-PIM

Busca no Gerenciador de software do YaST2, ordenado pela 1ª coluna (status), — “instalados”

Não lembro (nem encontro registro) de ter utilizado regularmente os benefícios do PIM, Baloo-file, Akonadi-server & correlatos (ou seus antecessores), desde quando comecei a usar o Kubuntu e o Debian KDE, há mais de 8 anos (2009). — No entanto, estiveram ativos esse tempo todo, consumindo recursos (RAM, CPU) e reduzindo o proveito que poderia tirar do hardware, quando exigido para outros esforços.

Em 16 Mai. 2016, um comentário e um link numa comunidade me incentivaram a examinar o assunto, — e acabei removendo PIM, Baloo, Akonadi do Kubuntu, do Debian KDE, e dos demais sistemas instalados desde então.

Porém, naquela época, o procedimento básico foi marcar para remoção cada pacote de uma lista de “aplicativos finais” que não uso, — lista construída a partir de consultas ao site KDE e outras raras páginas localizadas sobre o tema:

kmail
kaddresbook
kontact
korganizer
knotes
kjots
kalarm
akonadi-server
baloo-utils

Agora, no openSUSE Leap, comecei a busca por palavras-chave mais abrangentes, — “kdepim”, “baloo”, “akonadi”, — com os resultados ordenados pela primeira coluna (status), para agrupar os “instalados” no topo.

A partir daí, marquei para remoção cada pacote encontrado, — um de cada vez, para verificar as consequências, caso-a-caso.

Opções quando a remoção de um pacote afeta outros: — remover todos, manter, quebrar

Clique com o botão direito do mouse, selecione “Remover”, — e caso isso implique em remover outros pacotes, aparece uma janela de diálogo com a lista completa, e 3 alternativas para "resolução do conflito”:

Remover os pacotes que dependem dele
Manter o pacote selecionado (e os que dependem dele)
Quebrar as dependências

Nesse diálogo, tenha cuidado de não clicar em “Cancelar”, — pois isso não cancela a remoção solicitada antes, — apenas deixa o conflito sem solução (e você, sem saber como voltar a ele).

Para recuar, o caminho correto é selecionar a 2ª alternativa, — “Manter” o pacote cuja desinstalação iria lhe criar problemas, — e clicar em “Tentar novamente”.

Cuidado com listas apenas parcialmente exibidas, — verifique se não existe “mais…”

Tenha cuidado, também, com listas abreviadas ou incompletas, — com “mais…” escondido lá embaixo. — Ali mora o perigo.

Examine a lista, item por item. — Certifique-se de que não inclua nada vital ao sistema (Plasma workspace), nem algum aplicativo que você deseja manter (Dolphin, KFind, Okular, Ktorrent, Digikam, por exemplo).

Nestes casos específicos, recue, — e prossiga com a marcação dos demais pacotes encontrados.

Desativação da “Pesquisa de arquivos” (File search) nas Configurações do sistema (System settings)

É necessário ser tão radical? Nem tanto.

Desabilitar os serviços correspondentes, em várias seções das “Configurações do sistema” (KDE System settings), — como “Pesquisa de arquivos”(*), por exemplo, — é suficiente para que a maioria deles não carregue automaticamente, no início de cada sessão. Então, bastaria ter o cuidado de não clicar por distração no Kmail, Korganizer, Kalendar etc., para não acordar metade da tropa.

(*) Desativar “Pesquisa de arquivos” jamais afetou o mecanismo de pesquisa simples do Dolphin (Localizar), — nem o mecanismo de pesquisa avançada “Procurar arquivos / pastas” (KFind), — que continuam plenamente capazes de encontrar qualquer arquivo existente nos 3 HDDs + SSD externo (total 2,64 TB), por nome, extensão, tipo, data, tamanho, proprietário (User, Group) e/ou conteúdo (string dentro do arquivo), com a mesma velocidade de 2009 a 2016 (antes de começar a remover PIM, Baloo, Akonadi).

De início, foi o que fiz no openSUSE Leap 42.2, — como em outros sistemas acabados de instalar, — enquanto estes serviços ficaram quietos. Depois, começam os ajustes finos, e você acaba encontrando notificadores que resistem a desaparecer, e alguns serviços que insistem em ser carregados.

Depois de remover o que era possível, com as 3 palavras-chave, não foi necessário procurar o resto da antiga lista, — Kmail, Korganizer etc., — exceto para confirmar que já estavam desinstalados.

Dessa vez, portanto, bastou seguir o caminho inverso, — eliminar as “dependências”, — e os aplicativos caíram por tabela.

O resultado final foi a remoção de nada menos que 136 pacotes:

akonadi-calendar-lang
akonadi-calendar-tools
akonadi-calendar-tools-lang
akonadi-import-wizard
akonadi-import-wizard-lang
akonadi-mime
akonadi-mime-lang
akonadi-notes-lang
akonadi-server
akonadi-server-lang
akonadi-server-sqlite
akregator
akregator-lang
baloo5
baloo5-file
baloo5-lang
baloo5-tools
calendarsupport
calendarsupport-lang
eventviews
eventviews-lang
grantleetheme
grantleetheme-lang
incidenceeditor
incidenceeditor-lang
kaddressbook
kaddressbook-lang
kalarmcal
kalarmcal-lang
kcalutils
kcalutils-lang
kdav
kdepim-addons
kdepim-addons-lang
kdepim-apps-libs
kdepim-apps-libs-lang
kdepim-runtime
kdepim-runtime-lang
kdepimlibs4
kidentitymanagement-lang
kimap-lang
kldap
kldap-lang
kleopatra
kleopatra-lang
kmail
kmail-account-wizard
kmail-account-wizard-lang
kmail-application-icons
kmail-lang
kmailtransport
kmailtransport-lang
knotes
knotes-lang
kontact
kontact-lang
kontactinterface-lang
kopete
korganizer
korganizer-lang
kpimtextedit
kpimtextedit-lang
ktnef-lang
libgravatar
libgravatar-lang
libkdepim
libkdepim-lang
libKF5AkonadiAgentBase5
libKF5AkonadiCalendar5
libKF5AkonadiMime5
libKF5AkonadiNotes5
libKF5AkonadiSearch
libKF5AkonadiXml5
libKF5AlarmCalendar5
libKF5CalendarSupport5
libKF5CalendarUtils5
libKF5EventViews5
libKF5GrantleeTheme5
libKF5Gravatar5
libKF5IdentityManagement5
libKF5IMAP5
libKF5IncidenceEditor5
libKF5KontactInterface5
libKF5Ldap5
libKF5Libkdepim5
libKF5LibkdepimAkonadi5
libKF5Libkleo5
libKF5MailCommon5
libKF5MailImporter5
libKF5MailImporterAkonadi5
libKF5MailTransport5
libKF5MailTransportAkonadi5
libKF5Mbox5
libKF5PimCommon5
libKF5PimCommonAkonadi5
libKF5PimTextEdit5
libKF5Syndication5
libKF5Tnef5
libkgantt-lang
libKGantt2
libkgapi-lang
libkleo
libkleo-lang
libkolab1
libkolabxml1
libKPimGAPICalendar5
libKPimGAPIContacts5
libKPimGAPICore5
libKPimGAPITasks5
libKPimKDAV5
libksieve
libksieve-lang
libmeanwhile1
libmysqlclient_r18
libmysqlcppconn7
libotr5
libqgpgme7
libqimageblitz4
libreoffice-base-drivers-mysql
libxerces-c-3_1
mailcommon
mailcommon-lang
mailimporter
mailimporter-lang
mariadb
mariadb-client
mbox-importer
mbox-importer-lang
messagelib
messagelib-lang
pim-data-exporter
pim-data-exporter-lang
pim-sieve-editor
pim-sieve-editor-lang
pimcommon
pimcommon-lang

conforme os registros em /var/log/zypp/history, — entre 1:49 e 1:57 de 4 Ago. 2017. — Na verdade, a seleção começou 10 minutos antes, por volta de 1:39.

Foi uma “limpeza” muito mais completa, — além de muito mais rápida, — do que a registrada no Kubuntu e no Debian KDE.

Pacotes restantes do KDE-PIM, Baloo, Akonadi, — necessários ao sistema, ao Dolphin, KFind etc.

Ao final, ficam alguns componentes do KDE-PIM. — Não é uma remoção 100% completa, — mas já deixa o sistema nitidamente mais leve.

Vale notar que houve 2 “ensaios” (com erros), — primeiro, em 2 Jul., no Leap 42.2; e mais tarde, em 29 Jul., no Tumbleweed. — Agora, no Leap 42.3, finalmente consegui evitar erros.

Fica claro, de passagem, que o upgrade reinstalou todo o KDE-PIM, Baloo, Akonadi.

Snapper

Particionamento previsto para atender à brincadeira por vários anos

Partições padronizadas de 25 GiB pareciam mais do que suficientes para cultivar um belo criadouro de Linux e passar vários anos apenas regando, adubando, podando, enxertando aqui e ali, — até que o openSUSE Leap 42.2, instalado em Janeiro, ameaçou “dobrar a meta” dentro de poucos meses. — E ainda nem tinha nele todos os aplicativos instalados no Kubuntu ao longo de mais de um ano.

17 Jan. 2017 - Aos 27 minutos da primeira sessão, usava 5,37 GiB da partição-raiz.
26 Jan. 2017 - Ao concluir a configuração básica, usava 7,33 GiB.
9 Jun. 2017 - Atingiu 14,1 GiB, — consegui reduzir para 13,4 GiB (menos 0,7 GiB)
Depois disso, consegui reduzir para 11,0 GiB (menos 2,4 GiB, no mínimo)
2 Jul. 2017 - Ao remover o PIM e reinstalar algumas coisas, foi de 11,0 GiB para 12,8 GiB. Consegui reduzir para 11,4 GiB (menos 1,4 GiB)
3 Jul. 2017 - Consegui reduzir de 11,4 para 9,99 GiB (menos 1,5 GiB)

Somente nesses 4 episódios, — e deixando outros de lado, — o acúmulo eliminado manualmente já somava 6 GiB.

Ao iniciar o upgrade, em 3 Ago. 2017, o espaço usado já estava novamente em 11,5 GiB, — portanto, estaria em 17,5 GiB (pelo menos), caso não tivesse feito essas eliminações de pares de snapshots.

Durante o upgrade, o uso de espaço na partição-raiz chegou a 16,9 GiB, — ou seja, ultrapassaria 22,9 GiB, no mínimo.

Deletando pares de snapshots do openSUSE, — após atingir 17,0 GiB de espaço usado na partição

Felizmente, muito antes de chegar ao upgrade, comecei a entender, — na pele, — as implicações da partição BtrFS e dos “instantâneos” (snapshots) que, em tese, prometem desfazer (roll-back) qualquer desastre causado por alguma atualização, ou pela instalação de novos pacotes.

Na verdade, — como notou outro mortal, — nem saberia usar esse recurso, no caso de uma emergência.

Olhando os registros dos últimos 2 ou 3 anos, encontro poucos desastres onde esse recurso teria sido útil, — um triste upgrade do Linux Mint 18 “Sarah” Beta para 18.1 “Serena” (28 Jan. 2017), e uma infeliz atualização do Debian “Stretch”, quando ainda estava em desenvolvimento (30 Set. 2016).

Em suma, o “prêmio” cobrado por este “seguro” é desproporcional. — É um custo elevado, diário, permanente, — para um risco pequeno e de baixa ocorrência.

Estamos falando de um “usuário comum”, — com 1 máquina, — não de um “Administrador de sistema”.

Ter 2 ou 3 sistemas em paralelo (dualboot) é muito mais divertido. — O único problema é decidir “qual Linux usar hoje”. — É um preço que se paga com alegria e que retorna diariamente, na forma de aprendizado. De preferência, sem que se precise chegar a nenhum desastre.

Mas, o que significa “desastre”, — quando se tem vários sistemas em dualboot? — Se falha um, você usa outro.

Para quem gosta de brincar, sistema não há de faltar. — Mais valem 3 opções do que 1 “seguro”

Mesmo com o Linux Mint meio capenga, a partir de 31 Jan. 2017, — e coincidindo de deletar por acidente o KDE Neon, em 31 Mar. 2017, — ainda dispunha do Kubuntu 16.04 LTS (que nunca passou pelo risco de upgrade… embora hoje se apresente como “16.04.3”).

Ficou comprovado que 2 ou 3 Linux em paralelo, — se possível, em diferentes HDDs (e com mais de um Grub), — são um “seguro” bastante razoável, para um “usuário médio”.

E dispunha do openSUSE Leap 42.2, que, apenas 9 dias depois de instalado, — de 17 para 26 Jan. 2017, — já se colocava entre os “Top 3” no desempenho das tarefas essenciais do dia-a-dia.

Foi uma das mais gratas surpresas, — tamanha e tão rápida “usabilidade”, num sistema que jamais tinha visto antes, — após 7 anos limitado ao Kubuntu / Mint / Debian.

Deletando manualmente snapshots que proliferam automaticamente. — Nem sinal do nº 258

Portanto, pesquisei sobre o Snapper, — e deletei manualmente vários pares de snapshots, — até optar por desativar este serviço.

Limitando a proliferação de “instantâneos” (snapshots) no openSUSE

Primeiro, algumas providências para limitar o número de “instantâneos” (snapshots).

# snapper -c root set-config "NUMBER_LIMIT=2"
# snapper -c root set-config "NUMBER_LIMIT_IMPORTANT=2"

Desabilitando o uso do Snapper no openSUSE

Depois (pensando bem), desativar o Snapper, — editando USE_SNAPPER="yes" para "no", na última linha do arquivo “/etc/sysconfig/yast2”.

Normalmente, faria isso chamando “Dolphin - modo Root” pelo Menu K e clicando no arquivo para editá-lo com o Kate ou KWrite.

Porém, como se têm reforçado advertências contra o uso de aplicativos gráficos como Superusuário (Root), — e em várias distros essa opção já foi até eliminada do Menu, — padronizei o hábito de fazer esse tipo de trabalho pelo editor (F4) do Midnight-Commander (mc / mcedit, ou mc / nano).

Desinstalando “snapper-zypp-plugin” do openSUSE

Por fim (pensando melhor ainda), acabei por desinstalar o snapper-zypp-plugin, para acabar com a geração automática de pares de “instantâneos” (snapshots) do sistema, a cada atualização / instalação / remoção de pacotes.

Sim, porque você abre o Gerenciamento de software do YaST2, — desinstala 1 pacote, ou 100 pacotes, — e o espaço usado na partição-raiz… dá um salto.

Desinstalar esse plugin foi uma decisão de “usuário comum” (average user), — muito longe das responsabilidades de um Administrador de sistema. — Trata-se de um recurso poderoso. Apenas, nem sempre vale o “custo”, para um simples mortal.

Ao fazer upgrade do openSUSE 42.2 para 42.3, alguns pacotes removidos voltaram a se instalar e funcionar automaticamente, — todo o KDE-PIM, Akonadi, Baloo, — e o snapper-zypp-plugin.

Tudo bem, voltei a removê-los, — exceto snapper-zypp-plugin (por enquanto), — e a deletar 3 novos pares de shapshots. Já estava bem adestrado nessa arte.

Descoberta do “unreferenced snapshot” nº 258, completamente desgarrado

A decisão de não tornar a desinstalar o snapper-zypp-plugin, — por enquanto, — acabou justificada pela descoberta de um snapshot desgarrado (unreferenced snapshot), de nada menos que 6,19 GiB,

Isso, quando já estavam deletados todos os outros snapshots, — exceto nº 0 (sistema atual); e nº 1 (inicial, inapagável), — numa limpeza radical, tresloucada, porém ainda com resultados frustrantes.

O snapshot nº 258 só foi descoberto, quase por acaso, ao revisar a documentação de referência sobre o assunto (ver abaixo), — na dica “Deleting unreferenced snapshots”, sob o item 3.5.4 - Deleting snapshots.

Como o usuário não tem acesso à pasta (oculta) /.snapshots, ele só pôde ser examinado no Midnight-Commander, aberto pelo Root.

Por algum motivo, falta um arquivo XML com os meta-dados, — ou faltam os meta-dados no arquivo XML, — e o Snapper não “vê” aquele snapshot.

Snapshot nº 258 na Listagem, 2 dias depois, — mas não na Tabela (ver Imagens anteriores)

O snapshot nº 258 não aparece em nenhuma das tabelas geradas pelo comando snapper -ls, — usadas, até então, como guia para deletar pares de snapshots. — Só aparece (desde aquela época) em comandos de listagem de pastas / arquivos, como ls /.snapshots -al:

flavio@Linux5:~> su
Senha:
Linux5:/home/flavio # ls /.snapshots -al
total 4
drwxr-x--- 1 root root 54 Jul 3 08:01 .
drwxr-xr-x 1 root root 166 Jan 17 2017 ..
drwxr-xr-x 1 root root 32 Jan 17 2017 1
drwxr-xr-x 1 root root 16 Jun 7 21:03 258
drwxr-xr-x 1 root root 66 Jul 1 00:29 302
drwxr-xr-x 1 root root 98 Jul 1 00:29 303
-rw-r----- 1 root root 408 Jul 3 08:01 grub-snapshot.cfg

Linux5:/.snapshots # cd /.snapshots
Linux5:/.snapshots # du -sh 1
7,0G 1
Linux5:/.snapshots # du -sh 258
6,2G 258
Linux5:/.snapshots # du -sh 302
6,2G 302
Linux5:/.snapshots # du -sh 303
6,2G 303
Linux5:/.snapshots # du -sh grub-snapshot.cfg
4,0K grub-snapshot.cfg

Obs.: - Por princípio, os tamanhos indicados pelo comando du -sh [number] não se somam aritmeticamente, — pois há repetições, no caso dos pares “pre / post” (antes e depois de cada atualização ou instalação). — Note que a soma ultrapassaria os 25 GiB da partição.

A propósito:

flavio@Linux5:~> du --help

Summarize disk usage of the set of FILEs, recursively for directories.

Mandatory arguments to long options are mandatory for short options too.
-h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G)
-s, --summarize display only a total for each argument

Barra de progresso empacada e nenhuma atividade de CPU, — 18 minutos após concluir a atualização

Assim, foi possível identificar sua data de 7 Jun. 2017, às 21:03.

Trata-se de uma atualização que parecia empacada. — Aliás, tudo empacou naquela sessão. — O carregamento do openSUSE demorou quase 2 minutos. — A manutenção programada do BtrFS começou logo após o início da atualização (download), — e tudo ficou devagar, quase travando.

O arquivo /var/log/zypp/history indica que os 3 pacotes da atualização foram instalados com sucesso, em apenas 4m 30s, — completados meio minuto antes das 21:03, — mas a barra de progresso continuou empacada na metade do caminho por mais 26 minutos (sem nenhum indício de atividade de CPU no Conky ou no KSysguard), — e às 21:29 reiniciei o sistema. — O novo boot demorou cerca de 3m30s; e um reload do atualizador indicou que estava tudo atualizado.

Nota: - Talvez fosse interessante “afastar” (no tempo) os agendamentos do Notificador de atualizações e da Manutenção BtrFS, — para evitar encavalamento. — É verdade que, uma vez adquirida consciência disso, bastaria não autorizar as atualizações, até ter certeza de que a Manutenção não irá começar. Mas, sem saber quantos minutos esperar, como ter certeza?

Fato é que, após 6 meses, ainda não encontrei a configuração desses 2 agendamentos, no YaST2. — Resta ir à luta no Google, — e ter sorte de adivinhar as palavras-chave corretas.

Por outros motivos, — monitorar o tempo de Boot e o uso inicial de Memória RAM, — também seria interessante afastar ambos agendamentos para 10 minutos uptime, pelo menos.

Deletando “unreferenced snapshot” no openSUSE

Para deletar o snapshot nº 258 (agora), foram usados esses 2 comandos:

# btrfs subvolume delete /.snapshots/258/snapshot

Delete subvolume (no-commit): '/.snapshots/258/snapshot'

# rm -rf /.snapshots/258

Ou seja, — primeiro, deletar o “subvolume btrfs”; depois, o diretório. — Nada de apenas deletar a “pasta” pelo Midnight-Commander.

Com isso, o espaço usado desabou de 14,5 GiB para 8,31 GiB, — o menor tamanho, desde 11 Fev. 2017 (quando a instalação do “freshplayerplugin” elevou a marca de 8,29 para 8,35 GiB). — Uma redução espantosa, de 6,19 GiB, numa tacada só.

Depois disso, pode-se dizer que voltei a ter fé na Humanidade, — onde se incluem os desenvolvedores e colaboradores do Snapper.

Referência

Leap e Tumbleweed - Cronologia

Avanços obtidos com Leap (BtrFS) e Tumbleweed (ext4), no conjunto de sistemas Linux instalados

Na prática, as coisas se passaram com mais cautela do que pode parecer, pelo relato acima:

1) openSUSE Leap 42.2 foi usado regularmente por quase 5 meses, — ainda com folga suficiente, — antes do uso de espaço em disco se tornar alarmante.

2) KDE-PIM, Baloo, Akonadi foram desinstalados após longa observação, — já na fase de “ajuste fino”, — com direito a erros e correções.

3) openSUSE Tumbleweed foi instalado quase 5 meses depois, — em outra partição, formato ext4 “tradicional” (sem risco de snapshots), — e serviu para mais alguns testes & ensaios que hesitava em arriscar no Leap.

4) openSUSE Tumbleweed foi usado para testar a instalação de ffmpeg, — tinha um receio meio supersticioso de que pudesse afetar a leveza com que o Leap enfrentava o recurso “Páginas” do Facebook, — embora o repositório Packman já estivesse habilitado (mas sem uso) no Leap.

5) Só no final, arrisquei o upgrade do Leap 42.2 para 42.3, — com o novo DVD gravado, pronto para reinstalar, no caso de não dar certo. — Não havia como fugir ao risco. A versão anterior ficará sem suporte 6 meses após o lançamento da nova. Se ficar, o bicho come.

17 Jan. 2017 - (Leap 42.2) - Instalado em partição BtrFS (sdb2).

17 Jan. 2017 - (Leap 42.2) - Após 27 minutos do primeiro Boot, havia instalado apenas o Conky + 5 dependências (704 KiB baixados; 2,24 MiB instalados). Estavam ocupados 5,37 GiB da partição-raiz (3:39).

26 Jan. 2017 - (Leap 42.2) - Usados 7,33 GiB da partição-raiz, ao dar por encerrada a fase inicial de configuração (20:17).

9 Jun. 2017 - (Leap 42.2) - Deletados pares de snapshots “não-importantes”, com redução do espaço usado de 14,1 GiB para 13,4 GiB (21:35 ~ 22:00).

2 Jul. 2017 - (Leap 42.2) - Removido KDE-PIM, Baloo e Akonadi. — Por falta de atenção, acabaram removidos também vários pacotes necessários, como Amarok, K3b, Kdepasswd, Kdialog, Kdnssd, Kget, Kfind, Konqueror etc., reinstalados em seguida (21:20 ~ 22:24).

3 Jul. 2017 - (Leap 42.2) - Deletados pares de snapshots “importantes”, exceto os 2 últimos, com redução do espaço usado na partição-raiz de 11,4 GiB para 9,99 GiB (8:00 ~ 8:05).

3 Jul. 2017 - (Tumbleweed) - Instalado em partição ext4 “tradicional” (sdd2), para teste e comparação (19:36 ~ 22:05).

29 Jul. 2017 - (Tumbleweed) - Removido KDE-PIM, Baloo e Akonadi. — Por falta de atenção, acabaram removidos também alguns pacotes necessários, como Digikam e Kgpg, reinstalados em seguida. — Entre uma coisa e outra, o arquivo ~/.xsession-errors acumulou 2.533 linhas, num total de 292 KiB (19:40 ~ 20:00).

3 Ago. 2017 - (Tumbleweed) - Habilitado repositório Packman e instalado ffmpeg (19:33).

3 ~ 4 Ago. 2017 - (Leap 42.2) - Upgrade para 42.3, usando uma “receita” simples de 3 comandos em tty1, enquanto continuava trabalhando normalmente em tty7 (22:38 ~ 0:26, conexão 1,3 MiB/s).

4 Ago. 2017 - (Leap 42.3) - Removido KDE-PIM, Baloo e Akonadi (1:36 ~ 1:56).

4 Ago. 2017 - (Leap 42.3) - Instalado ffmpeg (10:57).

__________
• Publicado inicialmente em 2 Ago. 2017, no openSUSE 42.2, e desenvolvido até 6 Ago. 2017 no openSUSE Leap 42.3.
• O registro de datas + horas facilita localizar Fotos e Capturas de tela, — além das anotações no “Caderno de informática”, — caso precise verificar mais algum detalhe.

— … ≠ • ≠ … —