Translate

Mostrando postagens com marcador Conversão de imagens. Mostrar todas as postagens
Mostrando postagens com marcador Conversão de imagens. Mostrar todas as postagens

segunda-feira, 2 de janeiro de 2017

Instalação do Manjaro KDE 16.10.3 stable

Manjaro KDE 16.10.3 stable, instalado e atualizado
Manjaro KDE 16.10.3 stable, instalado e atualizado -

Este relato abrange desde a escolha do Manjaro, até a primeira semana de uso quase contínuo, após a instalação e configuração, — dividido nos seguintes tópicos, pela ordem:

  • Por que Manjaro
  • Download e sessão Live USB
  • Instalação (I), — sem Grub
  • Instalação (II), — com Grub
  • Boot e configuração
  • Limitando o Swap
  • Konqueror
  • Wine, — CorelDraw, Dreamweaver, MS Word
  • Idiossincrasias do Grub
  • Diversos (I)
  • Background do Grub
  • Verdana descomplicado
  • Diversos (II)
  • Primeiras observações
  • Wallpaper

Até onde pude constatar, o único problema da primeira instalação, foi ter optado por não instalar o Grub. — Instalar novamente foi o caminho mais simples e rápido, para quem ainda não tinha certeza da causa, nem conhecia nada de Manjaro ou de Arch Linux.

Desde a publicação inicial deste relato (2 Jan. 2017), foram registradas mais 3 observações, em relatos separados:


Por que Manjaro


Presença do Arch Linux no aprendizado, — mesmo sem nunca ter usado, até hoje

Na busca da menor dependência de “corporações”, este foi meu primeiro passo fora do universo Debian.

O caminho percorrido nos últimos 10 anos, — Kurumin, Kubuntu, Linux Mint, KDE Neon, Knoppix, — permitiu eliminar o Windows, porém as melhores soluções encontradas criaram nova “dependência corporativa”, agora em relação à Canonical, — já que ainda não consigo realizar todas as tarefas no próprio Debian.

O fato de o Manjaro estar em 5º no ranking de “visualizações” no Distrowatch, — indicador, portanto, apenas de “interesse em saber mais”, — teve seu papel na escolha. Mas, não só.

Há cerca de 1 ano, vinha examinando a “árvore” de distribuições Linux, — a partir dos “troncos principais” (sem descartar os “ramos”), — em busca de uma distro “não-debian” para romper a limitação seguida há uns 10 anos.

Depois de 2 tentativas toscas, com Fedora e Mageia, — péssimos “testes de trabalho em Live USB”, que só mostraram as deficiências de conhecimento, — ainda faltava tentar openSUSE, Arch Linux, Gentoo, Slackware, e/ou seus “derivados” mais usados e com maior suporte na web.

Arch Linux (11º no Distrowatch) é bastante recomendada por linuxeiros, em vários fóruns.

Da leitura, chamaram atenção alguns pontos:

  • Sem nunca ter usado Arch Linux, dezenas de páginas da Arch Wiki têm me ajudado a resolver problemas e aprender bastante, e povoam meus Bookmarks nos mais variados tópicos, — em linguagem simples e clara, focada, objetiva, bem estruturada, — o que acabou por dizer muito sobre essa distro, seus desenvolvedores e seu suporte comunitário.
  • Portanto, — mesmo sem entender “tecnicamente” do assunto, — não havia por que duvidar das afirmações (próprias e de terceiros) sobre seu foco na simplicidade e elegância de código (“correto”, “limpo”), transparência, minimalismo, leveza etc.
  • É “rolling-release”.
  • É desenvolvido pela comunidade, — não por (nem dependente de) uma empresa.

Sem condições de começar pelo aprendizado para construir um sistema Arch do zero (por comandos em tela preta), a escolha do Manjaro, — praticamente um dos poucos “derivados” em evidência (depois instalei também o Antergos, e por fim o próprio Arch), — baseou-se nas frequentes recomendações nos fóruns e em seu 5º lugar no ranking de interesse despertado, além das características levantadas pela leitura:

  • Alia características do Arch Linux, — consistência, leveza, velocidade, pacotes sempre atualizados, — com a simplicidade de instalação e alternativa de ambiente KDE por padrão.
  • É “rolling-release”, — nunca será preciso reinstalar, — estará sempre na “última” versão.
  • Suporte automático para instalação e uso de múltiplos Kernel.
  • É desenvolvido pela comunidade, — não por (nem dependente de) uma empresa.

Mas permanece o propósito de instalar e experimentar openSUSE, Fedora, Mageia, Gentoo, Slackware, e/ou algum de seus “ascendentes” e “descendentes”, — no devido tempo.

Download e sessão Live USB


Início do Torrent da imagem ISO do Manjaro KDE 16.10.3

31 Dez. 2016 - A imagem ISO foi obtida através do site oficial, e o download feito por Torrent.

Download, sha1sum e Torrent do Manjaro KDE 16.10.3

Não foi encontrado arquivo “sha256sum”, — embora recomendado, a oferta visível é apenas do “sha1sum”. Fazer o quê. — Deve haver algo que ainda não me contaram.

sha1sum copiado e colado no CTRL-F do Kate, para conferir

1º Jan. 2017 - Para não perder tempo nem correr riscos, o “sha1sum” foi copiado e colado no campo de busca do Kate, que compara com exatidão, sem necessidade de espremer os olhos.

Verificação se a imagem ISO do Manjaro KDE era isohybrid

Antes de seguir as indicações para gerar a mídia USB (Pendrive), foi verificado se a imagem ISO era mesmo isohybrid.

Gravação da mídia (Pendrive) pelo comando “dd”, com exibição do status de andamento

Por fim, usei o mais belo comando “dd” que já encontrei até hoje:

dd bs=4M if=/path/manjaro.iso of=/dev/sdX status=progress

Isso dispensou muita navegação e muito roer de unhas, na dúvida sobre o melhor parâmetro “bs”, — além de proporcionar informação permanente sobre o andamento da tarefa, — coisa que eu ainda não tinha encontrado, em dúzias de páginas pesquisadas ao longo de 2016.

Menu do boot com Live Manjaro KDE 16.10.3

Sem nenhum hardware especial, nem muito recente, dispensei a opção “Start (non-free drivers)” do Menu de Boot pelo Live Manjaro, bem como as demais, — explicadas sumariamente pelo Help (F1).

A resolução de tela (F3 Video Mode) já estava correta, e não havia motivo para experimentar outras opções de Kernel (F4), — “Opções seguras”, “Sem ACPI” ou “Sem APIC local”.

Seleção do Idioma (F2) no Menu de Boot do Live Manjaro, — e Teclado, no final da lista

De imediato, me interessava apenas escolher o Idioma (F2), — e dentro dele, o layout de Teclado, — antes de disparar o primeiro item do Menu de boot, — “Start Manjaro Linux”.

Tela inicial e Boas-Vindas, com informações do Manjaro importantes para o iniciante

3:02 (5:02 UTC) - A tela inicial exibe um quadro de Boas-Vindas ao iniciante, com informações importantes sobre o Manjaro, — em especial, o nome e a senha do usuário na sessão Live, — “manjaro”.

A senha foi exigida nada menos que 2 vezes, só no ajuste do fuso horário + habilitar sincronização de data e tempo, — necessários para salvar automaticamente as capturas de tela com nomes em formato “%Y-%M-%D_%H-%m-%S_Ma”, — de modo a se colocarem em sequência com as fotos de celular e capturas do Linux Mint, nomeados no mesmo formato.

Estado do Live Manjaro, minutos antes de iniciar a instalação no computador

Dada a confiança inspirada pelo Manjaro, — e a pouca utilidade dos “testes de trabalho em Live USB” de distros que desconheço por completo, como Fedora e Mageia, — fiz poucas configurações na sessão Live, e passei direto à instalação no computador, e documentá-la da melhor maneira possível:

  • Ajuste do Fuso horário + sincronização
  • Formatação do Relógio no Painel, para registro visual de data e hora
  • Montagem da partição “F:\” para salvar as capturas de tela diretamente em HDD
  • Inversão dos atalhos para captura de tela (PrintScreen) e delay (Shift-Print)
  • Tamanho e formato do Monitor do sistema (KSysguard), para documentar a instalação
  • Papel de parede, para dar identidade visual às capturas de tela do Manjaro KDE 16.10.3

3:26 - A penúltima captura antes da instalação registra que o Live Manjaro não montou nem utilizou nenhuma das partições Swap existentes no computador, — embora depois de instalado passe a montar e utilizar todas (inclusive as do Debian, cioso de seu Swap).

Instalação (I)


Instalador do Manjaro: — (1) Escolha do Idioma

A primeira instalação, — mesmo que sem falha, — não pôde ser carregada, — provavelmente porque não aproveitei para instalar o Grub do próprio Manjaro.

E como não sabia o suficiente para instalar o Grub do Manjaro, sem carregá-lo, — nem podia ter certeza de que esta fosse a causa do problema, — a solução mais prática foi reinstalar o sistema, de modo a cobrir também outras hipóteses.

Apesar da pouca familiaridade com algumas opções, — exigindo consultar alguns arquivos, e até pesquisar na web, — a primeira instalação foi bastante rápida, e se concluiu em 21 minutos.

Para isso, pode ter contribuído o fato de ter usado 2 partições vazias, — com a opção de não formatá-las.

Mais tarde, a segunda instalação, — com 7 formatações, — se concluiu em 24 minutos.

3:35 - Instalador do Manjaro — Escolha do Idioma

Instalador do Manjaro: — (2) Fuso horário / Localização

3:35 - Escolha do Fuso horário e da Localização, — formatos regionais de data, números etc.

Instalador do Manjaro: — (3) Escolha do layout do Teclado

3:36 - Escolha do layout de Teclado (PT-BR). — Nesse ponto, não foi encontrada opção de configurar o acesso ao terceiro nível

Opções do Instalador do Manjaro na área de particionamento. — Escolhido “Manual”

3:36 - Verificando as partições existentes no computador

3:37 - Opções de instalação: — “Lado a lado”, — “Substituir uma partição”, — “Apagar unidade”, — “Particionamento manual”.

3:37 - Escolhida a opção de “Particionamento manual”. — Não foram notados (nem explorados) os pequenos ícones (botões?) de “BIOS” e “MBR”, no alto, — aos lados da barra de seleção do HDD.

Escolha da partição de sistema (raiz, root) para a instalação do Manjaro Linux

3:38 - Partição raiz. — Escolhida a partição sdc2 (“Linux12”), de 25 GiB.

3:39 - Partição /home. — Escolhida a partição sdc6, também de 25 GiB, — cuja label “Linux15” será mudada para “Home12”).

Criar a segunda partição é uma experiência, — pois até agora, somente o Kubuntu LTS e o Linux Mint KDE tinham partições “/home” separadas, — e com tamanhos desnecessários (178,9 GiB e 74,8 GiB), uma vez que todos os arquivos de trabalho ficam nas partições Fat32 “E:\” (70 GiB) e “F:\” (180,1 GiB).

Nesse contexto, interessa verificar se 25 GiB é um tamanho pequeno, grande ou adequado a uma partição “/home” quase sem uso pessoal, — basicamente, para Wine, com CorelDraw, Dreamweaver e MS Word antigos (instalações mínimas), além das configurações que ficam em pastas e arquivos ocultos, — inclusive GoogleEarth, se for possível instalar no Manjaro (sem placa aceleradora 3D).

A opção de não formatar a partição de sistema, — nem a partição “/home”, — deveu-se ao fato de nunca terem sido usadas, desde quando foram criadas.

3:40 - Não foi encontrado meio de selecionar, — ou des-selecionar, — partições Swap.

As orientações oficiais são bastante simples, — deixando ao usuário a responsabilidade de decidir, conforme suas necessidades:

  • A partição Swap é considerada inteiramente opcional
  • A partição Swap é fortemente recomendada, — em especial quando se desejam usar as funções de “suspender” ou de “hibernar”
  • A menos que o usuário saiba o que está fazendo, recomenda-se que a partição Swap tenha o mesmo tamanho da Memória RAM
  • Dois sistemas operacionais instalado no computador podem compartilhar a partição Swap, — não são necessárias partições separadas

O que há de contraditório nessas 4 afirmações, é também o que há de liberdade de escolhas, — bem como de responsabilidade de cada um, pelo que escolher.

Enfim, — embora na sessão Live USB o Manjaro não monte nem use as partições Swap encontradas, — depois de instalado, passou a montar e utilizar todas, sem a menor cerimônia.

Usuário, ID, senha(s), nome do computador, Login automático, ao instalar o Manjaro

3:41 - Usuário, ID, nome do computador, senha (ou 2 senhas), login automático ou manual.

A opção de usar a mesma senha do Usuário para a conta de Administrador já vem habilitada. — Difere do Debian, onde parece mandatário ter 2 senhas diferentes, — e do Ubuntu (e “derivados”), onde parece nem haver opção de 2 senhas diferentes.

A opção de Login automático vem desmarcada, — e pode ser habilitada ou desabilitada mais tarde, nas Configurações do sistema (KDE). — É necessário desabilitar, quando se cria uma segunda conta, por exemplo, para familiares ou visitantes. Ou, quando há risco de estranhos ligarem o computador na sua ausência.

Opções de instalação do Grub em diferentes HDDs, na partição do sistema, ou não instalar

3:43 - Foi adotada a opção de não instalar gerenciador de boot, — pois já faz algum tempo que o controle do Grub é mantido com o Linux Mint. — Mas depois foi constatado que o Grub do Mint não consegue gerar uma entrada correta para o carregamento do Manjaro.

  • Ver “Idiossincrasias do Grub”, adiante.

3:44 - Resumo das opções sobre partições

3:44 - Instalando. — Início do slide-show.

3:56 - Instalação concluída. — Reiniciar agora, ou apenas Sair do Instalador. — Apenas Sair.

3:57 - Restart

4:04 - No Linux Mint: — “sudo update-grub”, — para detectar e incluir o Manjaro

4:06 - Fotos da entrada do Manjaro no Menu de inicialização gerado pelo Grub do Linux Mint

Menu de inicialização gerado pelo Grub do Mint não consegue carregar o Manjaro

4:07 - Tela preta. — Manjaro não pôde ser carregado a partir do Menu de inicialização gerado pelo Grub do Linux Mint.

Instalação (II)


“No need to manually assign a boot flag to any partitions”

Ainda sem saber exatamente qual o problema, — nem quanto tempo levaria para descobrir, ou aprender uma solução, — pareceu mais simples e rápido, simplesmente reinstalar o Manjaro, com 2 ou 3 pequenas variações, de modo a “cercar” algumas hipóteses.

Desconfiava de algum desentendimento entre o Grub do Mint (Debian / Ubuntu) e a estrutura própria do Manjaro (Arch Linux), — afinal, isso já ocorreu com o Knoppix (Debian), instalado no SSD externo.

Mas a causa também podia ser por não ter formatado a partição do sistema, — ou por não ter atribuído alguma flag, — ou outro detalhe não-identificado.

Uma vez que a primeira instalação tinha levado apenas 21 minutos (incluídos os 12 minutos de slide-show), — este era o caminho mais rápido para testar as 3 hipóteses.

10:04 - Instalador - Idioma

10:04 - Fuso horário / Localização

10:04 - Teclado

10:05 - Verificando as partições existentes no computador

10:05 - Opções de instalação / particionamento

10:06 - Partições do terceiro HDD, — inclusive o Manjaro em sdc2.

10:07 - Instalar em sdc2 - Formatar - Flags: Arranque?

10:10 - Pausa para pesquisa. — “Graphical installation guide” do Manjaro diz que não há necessidade de atribuir Flag de Boot. — O Instalador automaticamente atribuirá essa Flag às partições de Boot e de Raiz do sistema. — Portanto, essa hipótese foi eliminada de saída, sem necessidade de testar.

Nota: - O hardware (antigo) ainda usa apenas BIOS e MBR.

Instalação do Manjaro com gerenciador de boot (MBR) em /dev/sdc

10:12 - Partição /home em sdc6 - Formatar

Ao revisar essas opções, não foi vista qualquer confirmação de que as partições Raiz e Home seriam formatadas, por isso tornaram a ser marcadas. — Nova revisão, e nada, — marcadas de novo.

10:14 - Ainda nenhum meio de selecionar (ou des-selecionar) Swap. — Formatar a partição sdc10 como Swap, para ver o resultado. — Inócuo. — (Depois de instalado, o Manjaro montou e usou todas as partições Swap existentes).

10:14 - Instalar o gerenciador de inicialização (MBR - Master Boot Record) no terceiro HDD (/dev/sdc), — e mais tarde, configurar a Bios para procurar nele as instruções de Boot.

No mínimo, isso permitiria confirmar ou eliminar a hipótese de a falha estar na entrada gerada pelo Grub do Mint.

Resumo das opções e operações, antes de disparar o Instalador do Manjaro

10:15 - Usuário, ID, senha etc.

10:15 - Resumo das operações. — Duas partições serão formatadas 3 vezes, cada!

Sem encontrar marcado “Formatar”, — a cada vez que tornava a examinar as opções escolhidas para cada partição, — como voltar lá e desmarcar?

Enfim, como diz o ditado, “O que abunda não prejudica”. — Se havia dúvida sobre possível erro por não ter formatado, — agora essa hipótese seria fuzilada.

10:16 - Instalando (slide-show).

10:30 - Instalação concluída.

Portanto, a segunda instalação durou 24 minutos, — diferença de 3 minutos para mais, — em parte (1 minuto) por algumas pausas para pesquisa, — em parte (2 minutos) por serem feitas 7 formatações, contra nenhuma formatação na instalação anterior.

No próprio aviso de Instalação concluída, foi marcado “Reiniciar agora”, — e o Manjaro carregou sem qualquer problema, a partir de seu próprio Grub, em partições triplamente formatadas, — sem atribuir manualmente o flag de Arranque.

  • Ver “Idiossincrasias do Grub”, adiante.

Boot e configuração


Colocando o terceiro HDD no topo da lista, para ser procurado o Boot

10:34 - Ao reinicializar o computador, “Del” para entrar na Configuração da BIOS e colocar o terceiro HDD no topo da lista, — de modo que o Boot passe a ser procurado nele (caso não haja CD / DVD na bandeja).

10:35 - Menu de inicialização (Grub) com fundo preto, e a logomarca do Manjaro no canto.

10:36 - Tela de Login do Manjaro.

Aviso de 354 atualizações disponíveis, ao carregar o Manjaro pela primeira vez

10:37 - Primeiro Print do Manjaro instalado. — “Existem 354 atualizações disponíveis”.

Configurações iniciais:

  • Sincronizar data e hora automaticamente
  • Configurar Dolphin. — Montar partição “F:\”
  • Papel de parede
  • Configurar Spectacle. — Inverter atalhos PrintScreen / Shift-Print
  • Na inicialização, restaurar sessão salva manualmente. — Salvar sessão
  • Ativar NumLock ao iniciar o KDE Plasma. — Tecla de acesso ao terceiro nível
  • Montagem automática de partições adicionais
  • Desativar a Carteira do KDE (KWallet)
  • Login automático. — Entrar novamente após sair (“Encerrar sessão”)

Atualização completa do Manjaro, logo após a instalação no computador

11:02 ~ 11:28 - Sincronizar a base de pacotes do Octopi. — Atualização completa do sistema.

11:36 - Exame dos Repositórios, no Octopi: — Core, Extra, Community, Multilib (total: 10.216 pacotes), — e localização de “/etc/pacman.conf”.

11:37 - Limpeza de cache (pacotes instalados) no Octopi.

Crash das Configurações do sistema ao aplicar Tema e Decorações de janela, — mas aplicou

Mais algumas configurações:

  • Temas da área de trabalho → obter → Maia transparent
  • Decorações da janela → obter → Transparent oxygen
  • Bloqueio de tela — Não bloquear após X minutos. — Não bloquear ao reativar
  • Efeitos da área de trabalho → Cubo
  • Pesquisa de arquivos — desativar
  • Compositor — (Automaticamente escolhido: OpenGL 2.0; Método de escala: Preciso)
  • Efeitos da área de trabalho — Desativadas animações ao Minimizar / Maximizar

13:41 - Instalados, pelo Octopi:

  • Chromium
  • Conky, hddtemp, Xsensors, Sensors-applet
  • Fuseiso
  • Gimp
  • Gnome-screenshot
  • Krename
  • Konqueror

Limitando o Swap


Partições de sistema (Raiz), Home e Swap do Manjaro

Uma vez que o Instalador do Manjaro não ofereceu meios de selecionar quais partições de Swap seriam utilizadas, — e depois de instalado ele passou a usar todas, — restava editar seu arquivo “/etc/fstab” para restabelecer a ordem na bagunça.

Comentando (#) todas as linhas de Swap, — exceto uma, — no arquivo “/etc/fstab” do Manjaro

22:52 - A edição foi feita pelo Kate, no Kubuntu, consultando a planilha do particionamento e os comandos “sudo blkid” e “lsblk” no Konsole.

Localizado o identificador UUID da segunda partição Swap em sdc, — que estava sem a label “Swap12”, por ter sido formatada pelo Instalador, — bastou copiar, e colar no CTRL-F do Kate.

Todas as outras linhas referentes a partições Swap foram comentadas com um “#”, para serem ignoradas ao carregar o Manjaro, — com o cuidado de não fazer isso nas linhas das partições de sistema (“/”) e da Home (“/home”).

Konqueror


Às vezes o Manjaro carrega com o Yakuake aberto. — Tecle F12 para chamar / fechar

2 Jan. 2017 - Por algum motivo (ainda não descoberto, após 5 dias), o Konqueror continua abrindo com a sessão do Manjaro. — E tampouco foi descoberto meio de fazê-lo abrir em uma pasta ou partição escolhida.

O Konqueror havia sido examinado na véspera. — Tinha Busca avançada (CTRL-F), Modo de exibição de tamanho de arquivos, — mas faltavam Conversão rápida de imagens (PNG → JPEG etc.), e Montagem de imagem ISO

14:15 ~ 14:25 - Encontrados e instalados, via Octopi:

  • kde-servicemenus-rootactions
  • open-fuse-iso
  • krusader + arj, cpio, kdiff3, kompare, lhasa, unace, libkomparediff2

O Octopi, — aliás, a estrutura de oferta de pacotes, na qual o Octopi é uma interface gráfica, — exibe uma “ficha técnica” bastante precisa, sobre cada pacote.

No entanto, as descrições são frases curtas, — ou nem existem, — o que limita muito a busca pelo Octopi.

• Os repositórios do Kubuntu costumam ter descrições bem maiores e mais detalhadas que os do KDE Neon, — com impacto visível sobre a eficiência da busca do Synaptic, em um e no outro.

Além disso, os pacotes não são os mesmos do mundo Debian / Ubuntu, — e se você não sabe o nome do similar ou equivalente no mundo Arch / Manjaro, fica mais difícil encontrar.

Em compensação, o Octopi abre um diálogo oferecendo dependências, — mesmo quando opcionais. — No caso do Krusader isto poupou tempo (e neurônios, caso lembrassem).

• No Kubuntu & derivados, dependências opcionais são oferecidas pelo Synaptic, — mas apenas se você clicar no pacote com o botão direito do mouse, e procurar 2 submenus lá embaixo, — “recomendados” e “sugeridos”, seja lá qual for a diferença.

Ao “Comitar” (Aplicar) a instalação / atualização dos pacotes marcados, o Octopi oferece opção de “Executar em um terminal”, — onde exibe um resumo das alterações, tamanho etc., aguarda confirmação ou cancelamento, — e depois mostra o andamento das tarefas, tal como ocorreria usando comandos em um terminal (suponho).

14:28 - Limpeza do cache (pacotes instalados), no Octopi.

14:35 - O pacote “kde-servicemenus-rootactions” acrescentou ao Menu de contexto (right-click) do Konqueror (e do Dolphin) os submenus “Ações” e “Ações administrativas”, — incluindo opções como “Posse para” (Root, Usuário ativo, outros usuários) e “Alterar permissões”.

Montagem de imagem ISO pelo Konqueror (ou Dolphin) no Manjaro

15:29 - O pacote “open-fuse-iso” adicionou ao Menu de contexto do Konqueror (e do Dolphin) a opção “Mount / Unmount image”, — e ela aparece como uma nova pasta, ao lado da imagem ISO.

Modo de exibição de tamanho de pastas e arquivos em formato radial, no Konqueror do Manjaro

15:42 - Além do “Modo de exibição de tamanho de arquivos” em formato de blocos, parece ter sido acrescentada a opção em formato radial, — não percebida na véspera.

P.S.: - Trata-se do Filelight, — que pode ser aberto como aplicativo autônomo. — Mais tarde, passei a instalá-lo também em outras distros, onde ele não vinha por padrão.

Wine


Execução da instalação do Wine (via Octopi) em um terminal, no Manjaro

16:01 ~ 16:09 - Instalados Wine, Winetricks e Wine_gecko. — Mas, dessa vez, ficou para trás uma dependência opcional não oferecida no diálogo anterior, — e só percebida 4 dias depois, ao examinar as imagens para levantamento deste relato.

Mapa exportado pelo Corel em formato JPEG

16:11 ~ 16:57 - Instalados CorelDraw, Dreamweaver e MS Word, via Wine, — com pausa para instalar “Wine-mono”, via Octopi. — É possível que tivesse sido melhor aceitar a oferta do Wine para fazer isso, logo no início da instalação do CorelDraw. A opção adotada foi interromper, instalar “Wine-mono”, e recomeçar a instalação do CorelDraw.

16:42 - Apenas o CorelDraw abriu e funcionou, no primeiro momento. — Os demais ficam no aguardo de pesquisa e solução.

  • Dreamweaver abre, — porém invisível. — Um “Retângulo das Bermudas”, onde o ponteiro do mouse desaparece. — Isso também ocorre no KDE Neon User Edition, no Debian testing e no Kubuntu 17.04, — o ponteiro do mouse some, embora no Debian apareça o escudo inicial do Dreamweaver. — Right-click na Barra de tarefas não oferece “Fechar”. A solução tem sido terminar o processo, pelo KSysguard (Tabela de processos).
P.S.: - Tempos depois, descobri que bastava esperar — 1 hora, 10 horas, — até completar a primeira abertura do Dreamweaver. Depois disso, abre sempre em poucos segundos.
  • O MS Word começa a abrir, e aborta.

Interface “Pacman Log Viewer”, no Manjaro

19:22~19:25 - Instalação do Pacman Log Viewer, pelo Octopi. — Não parece oferecer as mesmas funcionalidades do Histórico do Synaptic, — hora e minuto em que os pacotes foram instalados, atualizados ou removidos, por exemplo.

Além disso, exibe separadamente os pacotes instalados, atualizados ou removidos, — o que dificulta saber a qual instalação ou atualização se deveu determinada remoção.

A solução para registrar o histórico segue pendente de examinar os logs na partição do sistema, — e eventualmente usar comandos para extrair o que interessa, introduzir quebras de linha nos pontos adequados etc. — Ou, descobrir / adotar outras rotinas e caminhos.

Idiossincrasias do Grub


Parâmetros “initrd” incompletos na entrada do Grub do Mint não permitem carregar o Manjaro

~23:00 - Após algumas pesquisas e comparações, ficou claro que o Grub do Linux Mint (Ubuntu) gera uma entrada incompleta, na última linha, — incapaz de carregar o Manjaro.

No Grub do Mint, — /boot/grub/grub.cfg:

initrd /boot/intel-ucode.img

Diferente do Grub do Manjaro, cuja última linha contém parâmetros mais completos:

initrd /boot/intel-ucode.img /boot/initramfs-4.4-x86_64.img

Sugestão de copiar e colar parâmetro do Grub do Manjaro para o Grub de outra distribuição Linux

Uma solução “imediatista” seria copiar e colar o que falta no Grub do Mint. — Porém, “grub.cfg” é apenas um arquivo gerado dinamicamente, e teria de fazer isso, de novo, a cada atualização, — o que é muito frequente, considerando todas as novas versões de Kernel nesse conjunto de Kubuntu LTS, KDE Neon, Debian testing, Kubuntu 17.04, Manjaro, — sem falar das atualizações eventuais do próprio Grub, no Linux Mint.

O mais prático é deixar o controle do Grub com o Manjaro, — e o Boot no MBR do terceiro HDD (sdc), — pelo menos por enquanto.

Foram consultadas as páginas:


Diversos


Montagem de partições “adicionais”, pelas Configurações do sistema (System settings) do KDE

3 Jan. 2017, 1:59 - Registro de lentidão “devagar-quase-travando” ao visitar uma “Página” do Facebook (não “Perfil”, “Grupo” ou “Feed de notícias”). — Surto de ocupação de CPU, e de Memória RAM.

19:19 - Configuração de montagem automática de mais algumas partições, para serem monitoradas no Conky desde o início de cada sessão.

4 Jan. 2017, 3:21 ~ 4:45 - Carregados todos os sistemas, sucessivamente, para testar o Menu de inicialização gerado pelo Grub do Manjaro. — Como não houve nenhuma atualização de Kernel, foi removida uma versão “obsoleta” do Kernel do KDE Neon, para teste posterior [No Kubuntu e no KDE Neon, a antepenúltima versão de Kernel é considerada “obsoleta”, e como tal passa a ser classificada pelo Synaptic].

5:09 - Desabilitando opção “Always try to have one preloaded instance” do Konqueror, na tentativa de eliminar sua abertura automática no início de cada sessão.

5:15 - Krusader

5:49 - Copiadas as fotos do celular para o HDD, via Kamera / Dolphin.

6:05 - Renomeadas as fotos de celular para o padrão “%Y-%M-%D_%H-%m-%S_NL”, no KRename.

Background do Grub


Exportando Golfinhos em formato PNG com o nome do Background do Grub do Manjaro

4 Jan. 2017 - Uma vez que o Manjaro vai ficar no comando do Menu de inicialização (Grub) por algum tempo, convinha substituir seu “background.png” por uma imagem mais feliz.

O primeiro passo foi copiar a imagem original, com outro nome, para ficar preservada.

A imagem dos golfinhos (JPEG) foi aberta no Gimp e “exportada” em formato PNG, — com o nome “background.png”, para fazer efeito sem necessidade de alterar nada nas configurações do Grub do Manjaro.

Transferindo a propriedade da imagem de fundo do Grub para o Usuário, no Dolphin

Para que o Gimp pudesse sobrescrever o antigo “background.png”, este arquivo teve sua “propriedade” transferida do Administrador (root) para o Usuário.

Isto serviu de teste para “Menu de contexto → Ações administrativas → Posse para o usuário ativo”, — recurso introduzido no Dolphin pelo pacote “kde-servicemenus-rootactions”, instalado via gerenciador gráfico de pacotes Octopi.

Grub do Manjaro: — Mantém a última escolha

Substituído o arquivo “background.png”, o efeito é imediato, — basta reiniciar o computador para ele ser exibido no Menu de inicialização.

O efeito não foi dos melhores, — as letras deveriam ser 100% brancas, — e amarelas na opção escolhida, com destaque em fundo cinza. — São as cores que têm dado melhor resultado, com essa imagem, no Grub de outros sistemas.

Ao contrário do padrão observado nos demais sistemas, o Grub do Manjaro vem configurado para selecionar, — e carregar automaticamente, após a contagem regressiva, — a mesma escolha feita na inicialização anterior.

Atualizando o Grub do Manjaro com “sudo update-grub”

15:20 - Para verificar o funcionamento das coisas, foi disparado um “sudo update-grub”, — após remover uma versão antiga de Kernel do KDE Neon.

Verdana descomplicado


Adicionando fontes Verdana (do Wine), em Configurações do sistema → Fonte → Gerenciamento de fontes

4 Jan. 2017 - Habituado a instalar o pacote “ttf-mscorefonts-installer” (via Synaptic ou “apt-get install”), já estava em crise de abstinência, por não encontrá-lo no instalador (gráfico) de pacotes Octopi, que veio no Manjaro, por default.

Após 4 dias, uma busca por “manjaro ttf-mscorefonts” levou a uma solução ridiculamente simples: Em “Configurações do sistema → Aparência → Fonte → Gerenciamento de fontes”, clicar em “Adicionar”, e escolher os 4 arquivos que já existam em uma partição montada, — a pasta oculta “/home/flavio/.wine/drive_c/windows/Fonts/”.

É pedida senha, há uma mensagem de erro, porém pede-se de novo a senha, — e surge um aviso de que é necessário reiniciar o(s) aplicativo(s) onde se desejam usar as novas fontes.

Legibilidade no Conky e no Chromium, antes e depois de instalar fontes Verdana

Não é uma questão de estética, — mas de legibilidade, com a tela a 70 cm dos olhos, — sem que precise fazer, no Manjaro, inúmeras configurações diferentes dos demais sistemas usados para o trabalho.

A ver, se esta solução tão simples também não se aplica em sistemas de origem Debian / Ubuntu, — e se nunca antes vi qualquer dica semelhante, apenas por estar perdida como agulha em um palheiro. — Incluir “manjaro” em uma busca por dicas técnicas, às vezes faz maravilhas.

Mirrorlist


Para registro, 2 momentos em que o espelho (repositório) falhou, causando dificuldades à instalação de pacotes ou à atualização do sistema, — sendo que, da segunda vez, já havia esquecido a solução encontrada antes:


Diversos (II)


4 Jan. 2017, 19:42 - Registro de lentidão “devagar-quase-travando” ao visitar uma “Página” do Facebook (não “Perfil”, “Grupo” ou “Feed de notícias”). — Surto de ocupação de CPU, e de Memória RAM.

5 Jan. 2017, 16:56 - Configuração das “Associações de arquivos”, — Chromium para Web, Gimp (e não Krita) para arquivos Gimp, KRename como segunda opção para Pastas, Gimp como segunda opção para vários tipos de imagens.

22:07 - Desabilitando “Apresentar janelas”, em “Cantos e bordas da tela ativa”.

Primeiras observações


Mais recursos e efeitos, — com mais estabilidade, — e com frequência, maior uso de Memória RAM

Após 1 semana de uso quase contínuo, o Manjaro KDE continua dando a mesma sensação de “estabilidade”, — a primeira palavra que ocorre é “serenidade”, — experimentada desde a sessão inicial em Live USB.

Efeito “Despedaçar”, — nem abala CPU ou a Memória RAM

Fechamentos inesperados de aplicativos ocorrem, — porém com menor frequência (e muito menos consequências) do que no Kubuntu 16.04 LTS ou no Linux Mint 18 KDE, por exemplo. — E neles ainda não cometi metade dos abusos (nem encontrei tantos recursos).

Os efeitos do Compiz — estilhaçamento ao fechar uma janela, deformação fluida ao arrastar, cubo ao mudar para outra Área de Trabalho — às vezes causavam uma leve “instabilidade” na renderização da tela, mas infelizmente não testei nem anotei se isto se devia ao compositor-padrão OpenGL2.0, nem se parou de ocorrer com a mudança para XRender, que era sempre preferível, neste hardware (sem placa de vídeo dedicada), e que acabei por selecionar.

As dificuldades ainda não superadas no Wine também ocorrem em outros sistemas com versões mais recentes do KDE, — ainda falta investir nessa área (que não uso tanto). — O mesmo pode ser dito do Konqueror (com ImageMagick, não se fica sem conversão de imagens).

A falha mais incômoda foi a impraticabilidade de navegar em “Páginas” (não “Perfil”, “Grupo”, ou “Feed de notícias”) do Facebook. Isso implica em receber apenas informações aleatórias, — ao gosto de terceiros, e filtrado por algoritmos de burrice artificial, — sem liberdade de buscá-las onde se encontram, e contribuir para fazê-las chegar a quem gostaria de vê-las. Só mais tarde “descobri” que isto podia ser contornado desabilitando “Hardware Acceleration” no Chromium.

Descobrindo desperdícios no modo de exibição “Mapa Radial” do Konqueror

O modo de exibição “Mapa radial”, do Konqueror, — ainda não encontrado nos outros sistemas, — em poucos dias já se mostrou muito mais útil do que o modo “Tamanho de arquivos” (em blocos).

P.S.: - Trata-se do Filelight, — que pode ser aberto como aplicativo autônomo. — Mais tarde, passei a instalá-lo também em outras distros, onde ele não vinha por padrão.

E isso, em uma questão do maior interesse no momento, — redimensionar as partições “Home1” (Kubuntu) e “Home2” (Mint) para tamanhos mais razoáveis, — abrindo espaço para partições “/home” de outros Linux.

Até o momento, a partição “Home12” (Manjaro) tem ocupação de 1,2 GiB, — menos de 5% de seus 24,5 GiB. — Tamanho mais do que suficiente, ao que tudo indica.

A ocupação de 14 ~ 15 GiB em “Home1” e ”Home2” decorre, em grande parte, das imagens ISO guardadas ali, — Kurumin, Knoppix, Manjaro, — e que poderiam estar em uma partição ext4 de uso comum (ou ser deletadas, com poucas exceções). Feito isso, resta uma massa descomunal de thumbnails, até agora desapercebida, que vem se acumulando desde 2014, pelo menos.

Comparativo dos sistemas Linux, — dentro das limitações pessoais

O Quadro comparativo (acima) é absolutamente pessoal, — tanto nas tarefas requeridas, quanto nas limitações para conseguir executá-las, — e reflete, em grande parte, o fato de já ter investido muito mais tempo no Kubuntu (do qual deriva o Linux Mint KDE), do que em qualquer uma das demais distribuições Linux já instaladas e experimentadas.

Também deve refletir, em boa proporção, o fato de o Kubuntu LTS e o Linux Mint 18 KDE serem distribuições “estáveis”, — enquanto as demais primam por ser pioneiras, ou rolling-release, ou experimentais, ou ainda em desenvolvimento. — (Deixemos de lado o Knoppix “Live CD / DVD”, que não é comparável).

O Konqueror, por exemplo, mostrava-se 100% íntegro e habilitado, no KDE Neon User Edition, — até 14 Dez. (Frameworks 5.29), — e parece significativo que o Manjaro seja, no momento, o único outro sistema, no Quadro comparativo, também com Frameworks 5.29.

Talvez seja um “exemplo prático” daquilo que tantas vezes lemos, — em termos conceituais, — sobre vantagens e desvantagens de se querer andar na frente.

Wallpaper


Pirenópolis (GO), em Março de 2015, by Tiago Caramuru

Foto de Pirenópolis (GO), por Tiago Caramuru, em Mar. 2015, — sem qualquer edição de imagem.

_________________
Relato produzido no Manjaro KDE 16.10.3 stable, de 2 a 6 Jan. 2017.

— … ≠ • ≠ … —

Não-debians


terça-feira, 27 de dezembro de 2016

Backup total e limpeza das partições de trabalho

Gráficos e tabelas do espaço aberto nas partições de trabalho nos discos rígidos, após a reorganização dos backups
Espaço aberto nas partições de trabalho, após a última etapa da reorganização dos backups

A reorganização dos backups decorreu da incorporação de um “disco” SSD externo de 1 Terabyte, seguida da instalação de um HDD interno de 1 Terabyte.

Em resumo, foi criada uma partição Backup1 (ext4) no novo HDD interno, — e uma partição “espelho” Backup2 (exFAT) no SSD externo, — o que permitiu retirar das partições de trabalho vários tipos de “backups parciais” (pastas de trabalho selecionadas) e vários “backups estáticos” (acervos a preservar inalterados).

Sequência da reorganização



Particionamento geral, — destacando as partições de dados e de backup

A reorganização dos backups e a “limpeza” das partições de trabalho foi concluída nos dias 24 e 25 Dez. 2016, — com salto de obstáculos, pelo fato de a partição “Backup1” (ainda) pertencer ao Administrador (root).

Em retrospecto, isso teve suas vantagens, — obrigou a mover algumas pastas pelo Konqueror (em modo root), — que apresenta um diálogo claro do número de arquivos, subpastas e Gibibytes, facilmente capturado com a tela.

Caso contrário, essas movimentações seriam feitas pelo Dolphin (modo usuário), — que não informa nada na tela, do início ao fim do processo, — exceto o nome do último arquivo, no final.

Só após a reorganização geral, foram explorados, — com calma, — os comandos “chown” e “chmod”, e transferida a “propriedade” da partição “Backup1” para o usuário.

Backups estáticos


Partição ext4 de 751,5 GiB, vazia, com 701,0 GiB livres

24 Dez. 2016 - Ao iniciar o trabalho, a nova partição “Backup1” (ext4, 751,5 GiB, HDD interno) encontrava-se ainda vazia, — exceto pela pasta de sistema “lost+found”, — e segundo o Dolphin, tinha 701,0 GiB livres.

Os 50,5 GiB não-“livres” representam 6,72% do tamanho nominal da partição.

Pasta “lost+found” vazia, até hoje, com tamanho “próprio” de 16,0 KiB

Passados vários dias, a pasta “lost+found”, — aberta no Konqueror em “modo root”, — apresenta-se sempre “vazia”, com 0 Byte, embora com tamanho “próprio” de 16,0 KiB.

Na linguagem do Konqueror, — “0 de 0, 0 B (0) de 0 B (0)”.

Início da cópia dos acervos de Backup2 para Backup1, pelo Krusader em modo root

Constatado que a nova partição “Backup1” (ext4, HDD interno) pertencia ao Administrador ou “Super Usuário” (root), foi utilizado o Krusader em “modo root” para copiar lá 4 pastas de “backup estático” (acervos a preservar inalterados) que já estavam no espelho Backup2 (exFAT, SSD externo).

Esse material seria eliminado das partições de trabalho “E:\” e “F:\” (onde ocupava espaço, por falta de alternativa), tão logo tivesse outra cópia em HDD, — para não confiar unicamente no SDD.

Terminada a cópia de 217 mil arquivos, após 2h37min

Esse conjunto de 4 pastas, — com 6.957 subpastas e 99,6 GiB, — foi copiado da partição exFAT do SSD externo para a partição ext4 do HDD interno, em 2 horas 37 minutos.

Ao final, o Dolphin indicava 601,9 GiB livres, — redução de apenas 99,1 GiB em relação à cifra inicial.

Ao que parece, o espaço “não-livre” cedeu 0,5 GiB para a guarda dos 99,6 GiB copiados.

Backup total de “E:\” e “F:\”


Deletando as tarefas do antigo backup parcial (pastas avulsas), no perfil Default

Para substituir o “backup parcial”, — pastas escolhidas de “E:\” e “F:\” que eram duplicadas na partição “Home1”, — foram deletadas do perfil “Default” do luckyBackup todas as antigas “tarefas”, que deixarão de ter utilidade.

Novas tarefas do luckyBackup, — copiar partições inteiras

Em seu lugar, foram criadas apenas 2 tarefas, — copiar as partições “E:\” e “F:\” (inteiras), para a partição Backup1 do novo HDD externo.

Início do backup completo das partições “E:\” e “F:\” para o novo HDD

O novo “backup total” foi iniciado às 15:41.

Um triângulo de alerta indica que as 2 novas tarefas não tinham data da última vez em que foram realizadas, — normal.

Backup entre HDDs internos SATA, concluído em 1 hora e 11 minutos

Embora envolvendo a transferência de 188 GiB, — quase o dobro da cópia realizada antes pelo Krusader, — o fato de ocorrer entre HDDs internos SATA (dois de 320 GB e um de 1 TB) fez com que transcorresse cerca de 4 vezes mais rápido, em 1 hora 11 minutos.

Correção do destino


Cometendo velhos erros, — pasta dentro de pasta, no destino do backup

Bastou examinar o resultado no Dolphin, para ver que havia repetido um velho erro do antigo backup parcial, — criar pastas separadas, no destino, em cada uma das quais, o luckyBackup criou uma subpasta, — quando o mais simples era deixar o próprio luckyBackup criar todas as subpastas em uma pasta só.

Pastas de destino movidas em 1 nível

Dessa vez, porém, foi adotada a solução mais simples e rápida, — mover as subpastas “/E” e “/F” para fora (e ao lado) de “part_E” e “part_F”, usando o Konqueror em modo root.

Essa operação não envolve movimentação “física” dos arquivos, — apenas altera seu caminho (path), dentro da “árvore”. — Tal como alterar o nome de uma pasta, e num piscar de olhos se altera o “path” de todo seu conteúdo.

É mais demorado dizer, do que fazer. — Depois disso, bastava deletar “part_E” e “part_F”, que ficaram vazias.

Sincronização rápida do luckyBackup, — transferindo apenas as novas capturas de tela

Corrigido o “path” nas tarefas, o luckyBackup aceitou os arquivos que encontrou no novo “local” de destino, — limitou-se a transferir as capturas de tela mais recentes, — e concluiu a sincronização em 2 minutos 13 segundos.

Eliminando pastas duplicadas


Cinco acervos duplicados em Backup1, — provenientes de “E:\” e de Backup2

Várias pastas de “backup estático” (acervos a preservar) estavam espalhadas pelas partições “E:\” e “F:\”, nos últimos anos, — e continuaram lá, mesmo depois de copiadas (algumas) para a partição Backup2, no SSD externo. — A ideia era manter pelo menos uma cópia em HDD interno, por segurança.

Com o backup completo, — tanto do Backup2 (SSD externo), quanto das partições “E:\” e “F:\”, — alguns acervos passaram a ter mais de 2 cópias.

Sincronização de pastas duplicadas, no Konqueror, para certificar que são absolutamente iguais

Em tese, bastava deletar as duplicatas desnecessárias, — mas era bom ter certeza de (ainda) serem absolutamente iguais.

Para não confiar na memória (achômetro), — em meio a várias reorganizações menores, nos últimos meses, — os pares de duplicatas foram sincronizados no Konqueror.

Tarefas de sincronização das 2 partições Backup1 e Backup2

Por fim, foi criado um segundo “perfil ” do luckyBackup, — com a opção de “destino FAT / NTFS”, — para sincronizar a partição Backup1 (ext4, HDD interno) na partição Backup2 (exFAT, SSD externo).

Parte dos ajustes feitos antes em Backup1, — renomear, mover, excluir pastas, — já tinham sido aplicados também em Backup2, para tornar menos demorada a primeira sincronização.

Partições de trabalho


Movendo acervos de preservação inalterada para Backup1 (e 2)

25 Dez. 2016 - A essa altura, já podia ser excluído um grande volume de arquivos das partições de trabalho:

  • Home1 - deletado o antigo backup parcial
  • Home2 - deletados vários acervos, agora em Backup1 / Backup2
  • E:\ - deletados vários acervos, agora em Backup1 / Backup2
  • F:\ - movidos vários outros acervos para Backup1 / Backup2

Exemplo de acervo a manter inalterado é a antiga pasta “Digital-Sony”, — com todas as fotos (e alguns vídeos) feitas desde 2003, — cujo conteúdo não pode se recuperado de nenhuma outra fonte, — exceto um punhado de velhos CDs / DVDs, de cuja durabilidade é difícil ter certeza.

As imagens originais (e seus dados Exif) não devem ser alterados, — para editar alguma foto, basta uma cópia nas pastas de trabalho.

Como parte da reorganização, a pasta foi renomeada “001_Fotos-digitais” (pois agora inclui imagens do celular), — as antigas pastas “mensais” foram reagrupadas em “anuais”, — e apenas as de 2016 foram mantidas na partição de trabalho.

Com essas e outras reorganizações, Home1, Home2 e “E:\” tornaram-se partições quase vazias, — e as 2 primeiras foram incluídas no backup dinâmico, pelo luckyBackup, — pois agora podem ser usadas como partições de trabalho.

CDs de instalação


Usando K3b para fazer backup (ISO) de CD / DVD de instalação de placas e aplicativos

Uma providência que já estava passando da hora, era fazer backup de antigos CDs de instalação de placas, periféricos e aplicativos, — pela gravação de suas imagens ISO na pasta Downloads1 (na Home1).

Formatos & permissões


Permissão geral de leitura, em alguns arquivos do Backup1 (ext4)

28 Dez. 2016 - Terminado o principal da reorganização geral dos espaços de trabalho e dos backups, a verificação dos resultados, — com as correções necessárias, — acabou impondo 2 ou 3 questões, que vinha evitando há cerca de 10 anos.

  • Partições “adicionais” ext4
  • Permissões, chmod, chown etc.

Por partições “adicionais”, leia-se, — partições que “não fazem parte” de nenhum sistema, — que não são “raiz” (“/”), nem “/home” de nenhum Linux. — Existem à parte, para leitura e gravação pelo Kubuntu, pelo Mint, pelo Debian, pelo KDE Neon, — ou qualquer outro, que venha a ser instalado em paralelo (dualboot).

As partições “E:\” e “F:\” nunca criaram problemas de “permissão” para renomear, gravar, deletar, — e isto foi um dos motivos para adotar o formato exFAT na partição “Backup2” do SSD externo.

  • Uma hipótese que parece explicar essa moleza toda: — “permissions are set at the time of mounting the partition with umask, dmask, and fmask and can not be changed with commands such as chown or chmod”. — Ou seja, partição FAT / exFAT é de quem “montar”.

Permissões restritivas, em alguns arquivos do Backup1 (ext4), — usuário não pode nem visualizar

Mas, na partição “Backup1” do HDD interno, finalmente foi adotado o formato ext4, — e voltaram os obstáculos que complicavam a vida do iniciante, 10 anos atrás. — Felizmente, agora com um pouco mais de noção do Linux.

A partição “Backup1” já nasceu pertencendo ao “Super Usuário” (Root), — o que não foi problema nenhum para o luckyBackup, rodando como “root”, — nem para o Krusader, também usado como “root” para criar as pastas iniciais, e colocar lá os backups “estáticos”, que não precisarão ser sincronizados (armazenamento de acervos).

Problema, foi quando muitas imagens não puderam ser, sequer, examinadas pelo “usuário comum”, via Dolphin, Gwenview etc.

Transferindo a “propriedade” da partição Backup1 para o usuário

29 Dez. 2016 - Depois de alguns comandos ignorantes, — tipo, “chmod -R 777” (que escancara as porteiras), “chmod -R 644” (que libera escrita mas impede de abrir a partição), — os neurônios chegaram à solução mais simples de todas:

sudo chown -R flavio Backup1

Transferir a “propriedade” da partição Backup1 para o “usuário”, — era o quanto bastava, para resolver todos os problemas, de uma vez por todas. — A partir daí, o “usuário” pode examinar qualquer arquivo, fazer buscas por conteúdo, ou o que bem entender.

Parte dessa simplicidade é devida ao uso do Dolphin, com “Exibir → Painéis → Terminal” (F4). — Aberto na pasta correta (“/media/flavio”), dispensa lembrar e digitar essa parte dentro do comando, e mostra o resultado na hora, — senão, atualize com F5.

Como a experiência posterior mostrou que, agora, todos os Linux conseguem lidar com essa partição “adicional” em ext4, fica aberto o caminho para migrar também as partições “E:\” e “F:\” para esse formato, — e matar a curiosidade sobre o espaço ocupado pelos arquivos, o espaço “livre” e o espaço “desperdiçado”, após a mudança.

Alterando as permissões, para que apenas o “proprietário” possa entrar, ver, escrever em Backup1

Depois disso, era até bobagem perder tempo com “chmod”. — Mas, quando a brincadeira dá certo, ninguém quer parar, — e foi aplicado um comando para restringir as permissões em todas as pastas, subpastas e arquivos da partição Backup1.

Não, que isso pareça aumentar uma suposta “segurança”, — essa preocupação é muito relativa, para um computador doméstico, sem rede, sem nada, — e as coisas também não são tão simples.

Primeiro, foi constatado que outra conta não tem acesso à pasta “/media/flavio”, — opção de ponto de montagem escolhida tendo isso em vista.

Segundo que, — no caso da partição Backup1, — os efeitos desse “chmod 700” são mais perecíveis do que alface. Bastam 2 minutos e 25 segundos, para o luckyBackup restabelecer as permissões de 11.846 subpastas e 224.710 arquivos, conforme os originais em “E:\”, “F:\”, “Home1” e “Home2”. — Se quiser alterar as permissões em definitivo, é preciso alterá-las nestas partições.

Terceiro, que ainda não foi encontrado “chmod” capaz de negar permissão para o “grupo” encostar um caminhão e levar a casa inteira, — backup incluído.

Sequência da reorganização



Formação sócio-econômica das partições e sua ocupação


Evolução do espaço disponível e ocupação das partições, nos últimos 8 meses

Criadas como verdadeiros latifúndios sem uso, — ao definir o particionamento geral dos 2 discos rígidos (HDDs) de 320 GB, em 2009, — 6 anos depois, as partições de trabalho “E:\” (70 GiB) e “F:\” (180 GiB), já davam sinais de esgotamento.

Àquela altura, já mal lembrava a folga dos primeiros anos, — quando dezenas de velhos backups em CD / DVD (numerados de 1 a 130-e-tantos) tinham sido, simplesmente, copiados de volta para a partição de trabalho (“F:\”) no disco rígido.

Aqueles velhos backups em CD / DVD tinham o péssimo hábito de incluir “n” duplicações, de dezenas de milhares de arquivos, — em alguns casos, todos os arquivos dos antigos HDDs, em várias datas diferentes; outras vezes, apenas os arquivos modificados desde o backup anterior, — além de muito lixo, de épocas em que salvava inúmeras páginas web, cada uma com milhares de penduricalhos inúteis (hábito substituído por PDF + TXT com texto, data e link).

Deletar em massa os repetecos inúteis, — mas, preservando sucessivas versões dos arquivos alterados, cuja consulta às vezes é necessária, — era tarefa insana, para ser feita de uma só vez. Quase impraticável, como trabalho com começo, meio e fim.

Busca em arquivos.TXT com listagens do conteúdo de antigos CD / DVD de backup

Porém, mantidos durante alguns anos na partição de trabalho (“F:\”), bastou ir arrastando as pastas realmente necessárias, para dentro da nova “árvore” de arquivos de trabalho, — e aproveitando para deletar o que era claramente inútil, — até que um dia, anos depois, o restante dos antigos backups trazidos de volta para o HDD já podia ser deletado.

Localização de arquivos por pasta em velhíssimos CDs / DVDs de backup

Às vezes, ainda faltava alguma coisa, mas bastava um “CTRL-F” por conteúdo, — na pasta com as listagens em TXT, — para localizar determinado CD / DVD, e copiar de volta mais algumas pastas, diretamente para a nova “árvore” de arquivos de trabalho.

Desse modo, a partição “F:\” acabou por se tornar uma “árvore” de pastas com (quase) todos os arquivos relevantes, guardados em backup desde a década de 1990, — inicialmente em disketes de 5¼’’, de 3½’’, depois em discos Zip, tudo em CD / DVD desde 2003, — e tudo (que de fato interessa) em HDD, de 2009 em diante.

Por volta de 2015, enfim, era cada vez mais raro, ainda precisar recuperar alguma coisa dos antigos backups em CD / DVD, — mas também acabaram as cópias em HDD que ainda pudesse deletar, para continuar abrindo espaço. — Em economês, “a oferta de espaço tornou-se inelástica, perante uma demanda invariavelmente crescente”.

Claro está que, àquela altura, o hábito de fazer backups em DVD já estava banido, de longa data, — substituído por backup das pastas de trabalho na partição “/home” do Linux1 (“Home1”), via luckyBackup ou Unison, — porém, novos CDs e DVDs, com material precioso, continuaram sendo recebidos dos colaboradores.

Nestes casos, o conteúdo era copiado para a partição de trabalho “E:\” (onde as cópias periódicas dos sites e blogs, zipadas, ocupam pouco espaço). O material dos colaboradores era trazido para HDD, como “backup estático”, contra eventual perda ou dano dos CDs e DVDs recebidos (e também contra falhas que, cedo ou tarde, afetam sucessivos leitores de CD-DVD, nos momentos mais inconvenientes).

Aliás, faz cada vez menos sentido, colocar mídia na bandeja, montar, examinar, ejetar, guardar etc., — é muito mais prático manter em HDD o material recebido. — No entanto, para trabalhar, é mais seguro copiar (apenas o que será usado), para uma pasta sobre aquele assunto, na “árvore” de arquivos de trabalho (“F:\”), onde documentos podem ser agrupados, editados etc., sem alterar os originais.

Desse modo, a partição “E:\” tornou-se um “armazém” de originais, — com backup na partição “/home” do Linux2 (“Home2”).

Só que, na prática, a teoria acabou sendo outra.

Conversão de arquivos TIFF em JPEG


Conversão em massa de arquivos TIFF em JPEG, em Setembro de 2015

No 2º semestre de 2015, um amigo vandalizou, — mandando um SSD portátil, com nada menos que 121.029.086.374 bytes (112,7 GiB) em imagens, planilhas e PDFs da maior preciosidade, para copiar.

Não havia espaço para isso, — mesmo deletando duplicatas (backups estáticos), além de 6.942 arquivos TIFF (após convertê-los em JPEG). — Foi necessário escolher apenas 28,8 GiB, para guardar (com cópia, excepcionalmente, em meia-dúzia de DVDs), antes de devolver o SSD portátil.

Como subproduto, várias coisas foram deslocadas, — do lugar “planejado”, para algum outro local “provisório”. — Em português claro, bagunçou-se o coreto.

É desnecessário dizer que, — desde aquela época, — espaço em disco rígido tornou-se assunto de sobrevivência. Uma carteira recheada resolveria isso num piscar de olhos, mas não era o caso, na época.

Infelizmente, em meados de 2015, ainda não tinha Conky na tela, — nem o hábito de fazer PrintScreen, para documentar (instantaneamente) a ocupação das partições, o movimento de pastas etc. — Os dados anotados fornecem poucos detalhes:

14 Set. 2015 - mogrify TIFF → JPEG em massa (diário geral). Havia 6.942 TIFF. — Em parte, haviam sido extraídos de arquivos PDF em vários formatos (para conferir), por isso, já havia JPEG duplicado, e nesses casos, bastou deletar os arquivos TIFF.

15 Set. 2015 - Examinando os JPEG gerados em massa, antes de destruir os velhos TIFF.

    6.915 TIFF
    Usados em F:\  → 163 GB
    Livre em F:\   →  16 GB
 
    23:23
 
    Usados em F:\  → 143   GB
    Livre em F:\   →  36,8 GB

Donde se supõe que foram liberados mais de 20 GB (18,6 GiB), pela conversão em massa de TIFF em JPEG, — mas não há como saber quanto espaço foi aberto, com outras providências, antes ou depois desse dia.

Conversão e eliminação do Photoshop


Automatização de tarefas em lote, no Photoshop, — converter em JPEG e fechar

Meses depois, novas providências se tornaram urgentes, para abrir mais algum espaço nas partições de trabalho.

4 Mai. 2016 - Começou a ser esvaziada a antiga partição “C:\”, — pela desinstalação de programas do Windows, seguida da limpeza de várias pastas sobreviventes, — com a simultânea eliminação de 7.048 arquivos Photoshop (“.psd”) existentes na partição “F:\”.

Converter em JPEG todos os arquivos Photoshop em uma pasta e todas as subpastas

Nos casos em que os arquivos “.psd” representavam a única cópia (originais de scanner), foi utilizada sua própria ferramenta de automação, — abrir todos os arquivos de uma pasta, “salvar como” JPEG, fechar, — após eliminar as respectivas duplicatas com “camada” (layer), que interromperiam o processo, solicitando intervenção manual.

Comparação com arquivos JPEG, — e excluir arquivos do Photoshop

8 Mai., às 7:02 - Quando restavam pouco mais de 119 arquivos do Photoshop (322,0 MiB), o Conky indicava a seguinte ocupação das partições:

    Home2    49,4 /  73,5 GiB
    Home1   150   / 176   GiB
    F       125   / 180   GiB - 54,6 GiB livres, cf. Dolphin
    E        50,0 /  70,0 GiB

A diferença entre a pasta de trabalho “F:\” e seu backup (“Home1”) é uma indicação aproximada do espaço aberto até aquele momento.

Ainda havia 6.513 arquivos Photoshop na “Home1”, totalizando 18,1 GiB, — e apenas 17,3 GiB livres, segundo o rodapé inferior do Dolphin.

18:11 - Após rodar o backup parcial, — só as pastas de trabalho, — pelo luckyBackup, a ocupação das partições ficou assim:

    Home2    52,2 /  73,5
    Home1   126   / 176    - Dolphin: 40,5 GiB free às 18:19
    F       125   / 180
    E        50,0 /  70,0

De passagem, isso indica que mais alguma coisa foi “armazenada” (backup estático) na “Home2”, — mas não em “E:\” (a menos que também já estivesse lá), — com cerca de 2,8 GiB.

“Disco” SSD externo de 1 TB


Árvore de diretórios originalmente existentes no SSD externo de 1 Terabyte

4 Jul. 2016 - A chegada de um SSD externo de 1 Terabyte (931,5 GiB), presenteado por um amigo, com 743,4 GiB livres, — e o conselho de deletar tudo que não apresentasse interesse, — alterou (para menor) o projeto de expansão do espaço de trabalho.

Ao invés de adquirir 2 HDDs de 1 Terabyte, agora bastaria adquirir 1 HDD de 1 Terabyte.

Como não ficou documentado o tamanho total dos arquivos recebidos com o SSD externo, — só uma listagem de todos os arquivos, e uma “árvore” de todas as pastas, em TXT, — resta a conta de subtração, que dá 188,1 GiB, — incluída alguma “perda” de espaço (NTFS) em blocos parcialmente ocupados, além da Lixeira ($RECYCLE.BIN), onde havia 6.673 pastas (6,5 GiB).

O registro da época, aqui no Byteria, indica que foram eliminados cerca de 140 GiB em arquivos + Lixeira, até o dia 6.

6 Jul. 2016 - Esvaziada a Lixeira e eliminadas milhares de subpastas em “Programas” e “Oldies”, — aplicativos e utilitários MS-DOS e Windows, desde a década de 1980, — o Dolphin indicava ocupação de 49,4 GiB e espaço livre de 880 GiB (“perda” de apenas 1,3 GiB, em NTFS).

Este foi, provavelmente, o menor índice de ocupação do SSD externo de 1 Terabyte, — que, pouco depois, recebeu o backup estático (armazenamento) de vários acervos, que até então tinham 1 única cópia em HDD, — passando, então, a 93,5 GiB ocupados.

Reparticionamento do SSD externo


Redimensionamento da partição (única) original, abrindo espaço para outras partições

25 Out. 2016 - O re-particionamento do SSD externo de 1 Terabyte serviu de ensaio para testar os planos de particionamento do futuro HDD interno de 1 Terabyte, — porém apresentou algumas características únicas, — por ter de ser feito sem perda dos arquivos já existentes.

A partição (única) NTFS, que já havia recebido mais alguma coisa (estava com 98,8 GiB), foi “encolhida” para cerca de 117 GiB.

No espaço liberado, foi criada uma partição estendida, de 814 GiB, — e dentro dela, uma partição lógica para backup, — em formato exFAT, tamanho 795 GiB, label “Terabyte” (atual “Backup2”).

Copiando 98,8 GiB entre 2 partições do SSD externo, em 3h20min

Em seguida, os 98,8 GiB de arquivos existentes na partição original (“encolhida”) foram copiados para a nova partição de backup.

Com isso, a partição original (encolhida) pôde ser deletada, — e criadas 3 partições primárias ext4 no espaço liberado.

Kubuntu 17.04 no SSD externo


Com a instalação do Kubuntu 17.04, a ocupação da partição de backup externo passou a ficar registrada

28 Out. 2016 - Após instalar o Kubuntu 17.04 Zesty Zapus no SSD externo, a partição de backup (795 GiB), — ainda com uma label provisória “Terabyte”, — finalmente foi incluída no Conky, e daí por diante sua ocupação passou a ser registrada em inúmeras capturas de tela.

Ensaio de backup total


Backup total da partição “F:\”

30 Nov. 2016 - Ensaio de backup total, avaliação do Unison x luckyBackup, e procedimentos a serem adotados quando fosse instalado um novo HDD interno de 1 Terabyte.

O “backup total”, — de todas as pastas em “E:\” e “F:\” (e não só das “pastas de trabalho”), — elevou essa ocupação da partição “Backup2” (então chamada “Terabyte”) de 116 para 319 GiB, em 2 etapas.

Também aqui, o ensaio com uma partição “Backup2” (então “Terabyte”), — em formato exFAT, — apresentou algumas características únicas.

Deixou de prever, por exemplo, o que ocorreria mais tarde, com as “permissões” dos arquivos, na partição “Backup1”, em formato ext4.

HDD 1TB e reorganização


20 Dez. 2016 - Instalado o novo HDD interno de 1 Terabyte.

24 Dez. 2016 - Reorganização completa dos backups, — “dinâmico” (com luckyBackup) e “estático” (acervos), — na partição “Backup1” (HDD interno), — espelhada em “Backup2” (SSD externo).

25 Dez. 2016 - Excluídos os antigos backups parciais em “Home1”, — e também os acervos que estavam espalhados em “E:\”, em “F:\”, e em “Home2”. — Agora, acervos e “backup total” ficam em “Backup1”, com cópia regular em “Backup2”.

Com isso, as partições “E:\”, “F:\”, e “Home2” voltam a ter espaço mais do que suficiente para trabalhar mais alguns anos, sem aperto algum, — falta esvaziar mais a partição “Home1”, — e começa a tarefa de repensar o melhor uso desses espaços liberados.

Sequência da reorganização



_________
Levantamento e relato produzidos de 27 a 30 Dez. 2016, principalmente no Kubuntu 16.04, — para evitar que o luckyBackup seja disparado a partir de mais de 1 dos sistemas Linux instalados.

— … ≠ • ≠ … —

Ferramentas &tc.