Translate

Mostrando postagens com marcador Psensor. Mostrar todas as postagens
Mostrando postagens com marcador Psensor. Mostrar todas as postagens

sábado, 3 de dezembro de 2016

Ensaio de avaliação com luckyBackup e Unison

Monitoramento de tensão e temperatura no backup inicial com Unison

O “ensaio” teve, como ponto de partida, o acréscimo de um drive externo SSD de 1 TB, — possibilitando um segundo backup, mais completo, — e como alvo, um futuro HDD interno de 1 TB, que vai alterar toda organização de arquivos, pastas e backups.

Trata-se de uma avaliação real, particular, específica: — (1) usuário “leigo”; — (2) envolvimento de todo o sistema (não uma “VM”); — (3) reflexos em todas as rotinas de trabalho; — e não uma “avaliação técnica”.

O objetivo é estudar alternativas e rotinas de backup, nesta máquina, para quando instalar o futuro HDD.

Sequência da reorganização



Estrutura de partições


Particionamento dos atuais HDDs de 320 GB: documentos no primeiro, backup no segundo

Há vários anos, todos os arquivos de trabalho ficam em partições Fat32 herdadas do antigo Windows XP, — aqui referidas como “E\:” e “F\:”, — de 70 GiB e 180 GiB, no primeiro HDD interno.

Também há vários anos, o backup é feito nas partições “Home2” (73,5 GiB) e Home1 (176 GiB), — pertencentes ao “Linux2” e ao “Linux1”, — no segundo HDD interno.

O drive externo SSD de 1 TB, — usado, e já um tanto antigo (2011), — não oferece tranquilidade para substituir (eliminar) os backups em HDD, por se tratar de tecnologia com menor vida útil, em número de gravações e leituras.

No entanto, permite acrescentar um segundo backup,— segurança adicional, — e isso abriu oportunidade para ensaiar novos métodos de backup, além de algumas correções nas rotinas seguidas até agora.

O objetivo “final”, portanto, era “ensaiar” novos procedimentos, — para quando for instalado um novo HDD interno de 1 TB, — que, com certeza, vai “revolucionar” a atual estrutura de pastas.

Como ficará claro, estruturas de pastas, nomes, rotinas etc. não costumam ser alterados com frequência, — pequenos “incômodos” ficam em observação por longos períodos, dando tempo ao planejamento de correções, e mais algum aprendizado.

A ideia é mexer o mínimo possível, ir devagar, e documentar tudo, — pois sempre haverá tempo para aprender, e será menos difícil corrigir as burradas.

Backup parcial com luckyBackup


Nomes desencontrados nas pastas de origem e destino dos backups

A rotina de backup seguida até aqui, — usando o luckyBackup, — abrangia só algumas das pastas existentes nas partições de trabalho “F:\” e “E:\”, — as pastas onde se concentram os arquivos de trabalho atualmente em uso.

Para receber os backups, tinha criado, manualmente, igual número de pastas de destino em “/Home1/flavio/Backup/”, — com nomes arbitrários, diferentes das pastas de origem.

Por inexperiência, as pastas de origem eram “clonadas”, criando uma sub-pasta, — com o nome correto, — dentro de cada uma dessas pastas.

Isso apenas complicava a navegação pelos backups, — abrir uma pasta, depois a sub-pasta, — sem nenhuma utilidade prática.

Opção de criar (clonar) a pasta de origem dentro da pasta de destino

Uma alternativa que se apresentou, logo no início deste “ensaio”, era marcar a opção “Do NOT create extra directory”, — e neste caso, apenas o conteúdo da pasta de origem seria duplicado dentro de cada pasta de destino.

A princípio, o “ensaio” foi direcionado neste sentido, — e após fazer a cópia do conteúdo, o próprio luckyBackup se encarregava de eliminar a “pasta extra” (clone), — o que foi bastante conveniente, pois o espaço livre na “Home1” já andava perto do limite.

Depois, relendo o aviso com calma, — ao marcar a mesma opção nas demais “tarefas”, — a palavra “clone” mostrou seu valor.

Inúmeras configurações, links, comandos, rotinas etc. estão associados aos nomes dessas pastas, nas partições “F:\” e “E:\”, — e é esse estado de coisas que será necessário restaurar, en cas de malheur, — mas isto seria bem mais difícil, se persistisse na burrice de colocar os backups em pastas com outros nomes, arbitrários.

Simplificando o luckyBackup


Novo comando do luckyBackup: — clonar as pastas de origem dentro de uma grande pasta de destino

Portanto, as “tarefas” do luckyBackup foram reorientadas para “/Home1/flavio/Backup/”, — e restabelecida a permissão para criar pasta “extra”, — vale dizer, “clonar” as próprias pastas de origem, dentro de uma grande pasta de destino.

Exceção foi feita aos 4 sites HTML, — agrupados em “/Home1/flavio/Backup/sites/”, — pois envolvem dezenas de milhares de links internos, e devem ser editados unicamente no Dreamweaver, para manter a integridade do conjunto (motivo de estarem em “E:\”, não em “F:\”).

Desastre “light”


Partição “Home1” lotada, — por não ter apagado (manualmente) as pastas antigas

Restou o problema de eliminar as antigas pastas com nomes arbitrários, — cada uma, contendo o clone de uma única pasta, — pois a “lógica” da nova rotina não as eliminaria automaticamente.

Isso ficou óbvio, quando a “Home1” rapidamente se entupiu.

Acontece que, por inexperiência, — e talvez devido a dificuldades para gravar em partições que não pertenciam ao Kubuntu, — há vários anos o luckyBackup vem sendo usado sempre em modo Root.

Menu → Utilitários → luckyBackup
Menu → Sistema → luckyBackup (super usuário)

Este “ensaio”, — e o exame para produzir o registro, — mostrou algumas consequências dessa opção, da qual já nem tinha consciência, após tanto tempo.

Entupida a partição “Home1”, o Dolphin não tinha permissão para eliminar as pastas antigas, — cada uma, contendo um arquivo oculto do luckyBackup, — ou seja, “propriedade do Root”.

Aliás, nem a Lixeira podia ser esvaziada, por conter 2 pastas com arquivos ocultos, — que não sei como foram parar lá, pois o luckyBackup costuma excluir por completo.

Dolphin do Kubuntu 16.04 LTS, — sem “Abrir como Root” no Menu de contexto (right-click)

O mais simples seria abrir a Home1 “como Root”, e deletar todas as pastas antigas, de uma vez só, — mas no Kubuntu 16.04 LTS, por algum motivo, o Menu de contexto (right-click) não oferece esta opção.

Comandos e mais comandos, — para não conseguir deletar uma pasta

O comando “sudo rmdir” também não foi capaz de excluir uma única pasta, — seria preciso entrar nela, dar outro comando para esvaziá-la, — ou abrir um parêntesis nesse aprendizado, para iniciar outro aprendizado… com o risco de ter de abrir um terceiro sub-parêntesis, para outro sub-aprendizado, — situação um tanto quanto kafkiana, no meio de um mini-desastre, no meio de um “ensaio” já meio enrolado.

Aliás, aprendizado de emergência para “deletar em massa”, — em momento de pânico, — não é recomendável.

Dolphin no Linux Mint 18 KDE, — “Abrir como Root” no Menu de contexto (right-click)

Nessas horas, é muito prático passar para o Linux Mint, — e resolver tudo numa tacada só, em cerca de 2 minutos, — usando o Menu de contexto para abrir a “Home1” (do Kutuntu) como Root.

Faltava habilitar a opção “Excluir” (sem passar pela Lixeira) no Menu de contexto do Dolphin do Mint

Faltava habilitar a opção de “Excluir”, — sem passar pela Lixeira, — no Menu de contexto do Dolphin, mas isso não tomou nem 1 minuto.

Dolphin aberto “como Root”, — “Excluir” 21 pastas (cheias) de uma só vez

Com isso, bastou selecionar todas as pastas começadas por “b_”, — e mandar Excluir, — para a “Home1” ficar com apenas 44,8 GiB ocupados e 122,2 GiB de espaço livre.

Agora, — ao fazer o levantamento do “ensaio” e produzir um registro detalhado, — é uma boa hora para aprender mais, sem risco de cometer burradas.

O comando “rmdir” serve para apagar diretórios vazios. — Para diretórios cheios, poderia usar “rm b_Byteria/ -R”, por exemplo, que apagaria o conteúdo (recursivamente), sem fazer perguntas, — mas também, sem direito a arrependimento.

No Kubuntu, as configurações do Dolphin e do Konqueror, — seção “Serviços”, — não oferecem a opção “Abrir como Root”, para ser habilitada.

No entanto, digitando “root” no Menu do Kubuntu, teria encontrado “Menu → Sistema → Krusader (modo Root)”, — que resolveria o problema num piscar de olhos.

Reorganizando pastas de origem


Diferenças de ordenamento alfanumérico entre o Dolphin e o Nemo

O “ensaio” também foi aproveitado para fazer algumas mudanças de nome nas pastas de origem:

    _Novas-no-Site   → 000_Novas-no-Site
   _Scanner_entrada → 000_Scanner_entrada
000_print-screen    → 000_print-screen

O motivo, — em observação há alguns anos, — é que aplicativos diferentes usam critérios diferentes de classificação alfanumérica, em seus diálogos de navegação para localizar arquivos, — de acordo com sua origem (Gnome, KDE) e/ou as “bibliotecas” que utilizam.

Nos diálogos de alguns aplicativos, arquivos com nomes iniciados por sublinhado (“_”) são colocados no topo, — tal como no Windows XP, — enquanto, em outros, a classificação ignora o sublinhado e considera apenas as letras ou números que vêm depois dele.

Adaptação dos comandos luckyBackup aos novos nomes de pastas de origem

Portanto, o único modo de garantir que uma pasta muito utilizada apareça sempre no topo, é usar nomes começando por “000”.

Felizmente, a pasta “000_print-screen” é recente, e já incorporava essa manha, — pois qualquer alteração em seu nome implicaria alterar as configurações do Kubuntu LTS, Linux Mint, KDE Neon, Debian, e Kubuntu 17.04 Zesty Zapus.

Obs.: - Diferentes quantidades de zero, — em especial, quando seguidos de outro(s) número(s), — também podem dar margem a classificações diferentes, em diferentes aplicativos (Verificar pastas contendo arquivos com nomes apenas numéricos, como páginas de livros).

Re-clonagem com luckyBackup


Início da re-clonagem das pastas selecionadas, pelo luckyBackup, com monitoramento de energia

Deletadas as pastas do antigo backup, a “Home1” ficou com 44,8 GiB ocupados e 122,2 GiB de espaço livre.

A soma dá apenas 167,0 GiB, — e de fato, esse parece ser o limite “real”, embora o tamanho nominal seja de 176 GiB, — pois meia hora antes (22:56), quando a ocupação da “Home1” chegou a 167 GiB, o sistema emitiu alerta de 0% de espaço livre.

Essa ocupação de 44,8 GiB, após a “limpeza”, inclui 2 pastas que já tinham sido clonadas antes, — total ou parcialmente, — pelas novas regras de backup, e que por isso não foram apagadas. Também inclui 2 pastas que ainda estavam na Lixeira, que só foi esvaziada mais tarde, com nova ajuda do Linux Mint.

Relatório do luckyBackup, ao final da re-clonagem

O luckyBackup foi disparado, então, às 23:31, — com monitoramento de temperatura e das saídas da fonte de energia, — e concluiu a re-clonagem em 52 min 51 seg, por volta da 00:24, relatando a transferência de 104,65 GB.

O Conky indicava ocupação de 143 GiB na “Home1”, — e o Dolphin indicava 24,5 GiB livres, — o que soma 167,5 GiB.

A temperatura do primeiro núcleo (Core0) ficou abaixo de 61ºC, nos últimos 10 minutos da cópia, — mas os níveis de energia não foram documentados.

Backup total com Unison


Ao abrir o Unison, é necessário escolher um “Perfil”, — criar um, se não existe, — ou sair

O segundo backup, — abrangendo todo o conteúdo das partições “E:\” e “F:\” para uma pasta na partição “Terabyte” (exFAT, 795 GiB), — foi “ensaiado” no Unison, por vários motivos:

  • Explorar uma alternativa, que já não lembrava como funciona

  • Evitar eventual conflito ou sobreposição de arquivos ocultos (logs) do luckyBackup, por desconhecer praticamente tudo sobre as entranhas de seu funcionamento

Se até então não lembrava como funciona o Unison, depois de 6 dias continuo não lembrando absolutamente nada, — ao ponto de duvidar que o tivesse usado regulamente, durante 2 anos, de Set. 2012 a Ago. 2014, com um intervalo entre Fev. e Ago. 2013, — até encontrar os logs da época, com todos os detalhes (ver “História antiga”, no final).

Crash em todas as tentativas de criar um novo “perfil” no Unison

A primeira coisa que o Unison exige, é que você escolha um “Perfil”, — e felizmente, no Kubuntu 16.04 LTS, já veio com um perfil “Default” (vazio).

Isso porque, no Kubuntu 16.04 LTS, ainda não foi possível criar novo perfil, — o assistente “Profile creation” fecha abruptamente (levando junto o Unison), tão logo escolho a pasta ou unidade de origem, ou de destino (o que tentar primeiro), — e continua impossível, após 6 dias.

Adicionando uma “Preferência” ao perfil “Default” do Unison

A única solução viável foi editar o perfil “Default”, adicionando as 3 únicas coisas que pareciam fazer algum sentido, para um pobre leigo ignorante:

  • Preferência → Fat → Boolean: True
  • Origem → “/media/flavio/F” — (partição “F:\”)
  • Destino → “/media/flavio/Terabyte/Backup/part_F”

O que entender por “no archive files were found”, — em uma partição cheia até as bordas?

Um aviso aterrorizante diz um monte de coisas ininteligíveis, — tipo, “no archive files were found”, — exceto a parte onde aventa a hipótese de a “culpa” (sei lá do quê) ser do fato de se tratar da primeira sincronização (ufa!).

Pode-se imaginar que esteja reclamando (apenas) da pasta de destino, que de fato ainda estava vazia, — ou talvez, da inexistência de arquivos de log (no plural?), porque ainda não houve sincronização, — mas ter de “imaginar”, é tudo o que pode haver de mais inútil, para um usuário, em especial se for leigo em TI.

Proposta apresentada pelo Unison após a comparação da partição de origem com a pasta de destino

Mas, usuário teimoso não pede para sair. Clicado “Ok”, Unison começou imediatamente a procurar alterações (Looking for changes), — e após 48 minutos apresentou a lista de todas as pastas existentes em “F:\”, com setas verdes apontando para a direita, — sinal de que não existia nada “mais novo”, no destino, — nem nada que não existisse na origem.

Ícones na Barra de ferramentas permitem alterar, — cada linha da lista, ou várias, ou todas, — para “Skip” (pular), “Right to left” (inverter), “Left to right”, “Merge”.

Estavam desabilitados, naquele caso, os ícones “Diff” (ver as diferenças), e “Details” (detalhes).

Mais à direita, ícones “Go”, — executar as operações sugeridas (e/ou editadas), — “Rescan” (examinar tudo de novo), “Change profile” (escolher outro perfil).

Unison copiando 175 mil arquivos (135,7 GiB) para uma pasta na unidade externa SSD

Disparei “Go” e, após 1 h 55 min, concluiu-se a cópia inicial de todo o conteúdo da partição “F:\” para a pasta escolhida na partição “Terabyte” do drive externo SSD.

Fiquei, então, com um perfil “Default” plenamente habilitado para desempenhar regularmente a primeira metade das tarefas de backup.

Sem conseguir criar um novo perfil, — tentativas sempre acabando em crash, — cheguei a adicionar mais 2 pastas ao perfil “Default”, para ver se seriam aceitas como nova origem e novo destino, mas não é assim que as coisas funcionam:

Fatal error

Wrong number of roots: 2 expected, but 4 provided (/media/flavio/F, /media/flavio/Terabyte/Backup/part_F, /media/flavio/E, /media/flavio/Terabyte/Backup/part_E)
(Maybe you specified roots both on the command line and in the profile?)

Embora “fatal”, esse erro não causa fechamento abrupto do Unison.

Duplicando e renomeando perfis do Unison no Dolphin

A solução encontrada foi abrir a pasta “/home/flavio/.unison/”, fazer cópias do perfil “Default”, — e editar os parâmetros pelo Kate, — em modo usuário, pois o Unison não estava rodando como Root:

cp default.prf backup_E.prf
cp default.prf backup_F.prf

Com pequenas alterações de “F” para “E”, o perfil que faltava ficou assim:

# Unison preferences
fat = true
root = /media/flavio/E
root = /media/flavio/Terabyte/Backup/part_E

Por fim, o perfil “Default” foi novamente alterado, e excluída qualquer referência ao drive externo SSD, — que não permanece plugado a maior parte do tempo, — caso contrário, seria impossível abrir o Unison, para conferir alguns detalhes deste relato:

# Unison preferences
root = /home/flavio/Wallpapers/
root = /media/flavio/Home2/flavio/Wallpapers/

Sumário → Detalhes, ao final da sincronização pelo Unison

Porém, mesmo algo tão inocente quanto sincronizar wallpapers entre as partições “Home1” e “Home2” acabou apresentando surpresas, — por exemplo, um arquivo “.directory” (oculto) com especificações que são só do Kubuntu.

Desmarcado (“Skip”) o arquivo oculto, foi feita a sincronização, de modo que os mesmos wallpapers agora possam ser encontrados tanto na “Home1” quanto na “Home2”.

Unison identifica o que foi deletado, e propõe “propagar as mudanças” para a pasta de destino

Em seguida, foram deletados alguns arquivos duplicados, — cujos nomes haviam sido alterados só no Kubuntu ou só no Linux Mint, — e o Unison identificou a mudança com perfeição, propondo deletar as duplicatas também na outra pasta.

Ou seja, a “bi-direcionalidade” não levou ao erro de recriar o que havia deletado, — coisa que agora é lógica e óbvia, mas até então, para um leigo absoluto, não era certeza.

Instalação


Unison instalado no Linux Mint, para verificação: — sem nenhum “perfil”

Inicialmente, foi instalado no Kubuntu 16.04 LTS o pacote “unison (2.48.3-1ubuntu1)”, — sem interface gráfica, — por engano.

Constatado o engano, foi instalado o “unison-gtk (2.48.3-1ubuntu1)”, localizado e instalado pelo Synaptic, — que não apresentou dependências, embora seja recomendado instalar também “openssh-client:i386”, e sugerido “unison-all-gtk”.

A simples instalação do “unison-all-gtk” não impediu que o “Profile creation” continue fechando abruptamente o Unison, tão logo se clica em qualquer opção de pasta de origem ou destino, — inclusive “Other”.

A instalação do “openssh-client:i386” implica remover “openssh-client”, — por isso, foi testada inicialmente a instalação do “ssh-askpass-gnome”, — o que também não fez diferença no comportamento irregular.

Por fim, foi instalado “openssh-client:i386”, — com remoção do “openssh-client”, — também sem alterar a rotina de encerramento abrupto.

Depois disso, o Synaptic passou a recomentar “openssh-client”, — o que implica em remover “openssh-client:i386”, — um loop sem fim, portanto.

Como última possibilidade, foi removido “unison” (sem interface), — que não é requisito para o “unison-gtk”, — mas tampouco alterou a situação.

Unison no Linux Mint: — mesma “proposta” do Kubuntu para as pastas “Wallpapers”

Para verificação, no Linux Mint 18 KDE foram instalados, — simultaneamente, via Synaptic, — “unison (2.48.3-1ubuntu1)” + “unison-gtk (2.48.3-1ubuntu1)”.

Ao abrir pela primeira vez, no Linux Mint 18 KDE, “unison-gtk” não trazia nenhum “Perfil”, — mas o “Profile creation” funcionou perfeitamente, até o final, — e a comparação das pastas “Wallpaper” das “home1” e “home2” apresentou a mesma proposta de sincronização. — Apenas, não mandei executar, pois havia reservado essa tarefa para o Kubuntu 16.04 LTS.

Até onde chega a compreensão de um usuário leigo, as diferenças mais evidentes são: — (a) o Mint permanece com Kernel 4.4.0-21, enquanto o Kubuntu incorporou a revisão 4.4.0.51 minutos antes da instalação do Unison, e agora já está na 4.4.0-53, mas persiste o problema; — (b) alguns traços de origem Gnome, um pouco mais pronunciados no Mint KDE do que no Kubuntu; — (c) equipe maior e mais “profissional” no Kubuntu vs. equipe menor e mais “artesanal” no Mint.

Este é o primeiro item, em que o Kubuntu 16.04 LTS fica nitidamente atrás do Linux Mint 18 KDE, — em geral, é no Kubuntu 17.04 Zesty Zapus (development branch), no Debian testing, e até no KDE Neon 4.8, que (ainda) não consigo realizar algumas tarefas, — porém o backup também é a única tarefa que geralmente não tento fora do Kubuntu, para evitar conflitos ou confusões.

Para leitura


Manual do luckyBackup no Help (F1), com texto minucioso e fartamente ilustrado

À primeira vista, portanto, — nesse nível intuitivo (“tatear às cegas”), sem maiores conhecimentos, — o Unison atende razoavelmente bem a 2 ou 3 “tarefas”, — se não forem muito frequentes, — devido à necessidade de trocar de “perfil” ao final de cada uma, para realizar a próxima.

Sob esse aspecto, é muito mais prático usar o luckyBackup, — onde você pode incluir 20 ou 30 “tarefas” em um único “perfil”, — e resolver tudo com um clique só.

É claro que há maneiras de automatizar tudo isso, no Unison, — e no luckyBackup, também, — inclusive marcando hora de madrugada (se a máquina permanece ligada), ou “ao inicializar”, por exemplo.

Há vários anos, desisti da automação, por 2 motivos principais: — (a) Incerteza sobre partições eventualmente não-montadas, como é o caso agora da unidade externa SSD; e — (b) Retardar o backup de um punhado de arquivos novos ou editados nas últimas 24h ou 48h é muito menos “crítico” do que excluir automaticamente o backup de inúmeros arquivos, deletados sem medir as consequências (muitas vezes, o backup “atrasado” resgatou a imprudência).

O segundo motivo poderia ser amenizado, — digamos, por uns 4 dias, — pela manutenção automática de até 4 “snapshots”, desde que o espaço exigido atenda à relação custo / benefício:

Snapshots to keep
Every time a task is run the source data are backed-up as they are at that specific time.
This is called a snapshot !!
luckyBackup can hold a number of snapshots so that it is possible to revert to any one of them.
Define the maximum number of snapshots you wish to keep, by clicking on the arrows of the spin-box.
If that number is reached, older snapshots will be deleted when the task is run again.
The default number of snapshots to keep is 1.

Fica patente que falta ler muito sobre o Unison, — e sobre o luckyBackup.

Para facilitar a consulta, foram reunidos em local de fácil acesso alguns documentos de ajuda encontrados no Help, no comando “unison -doc” e em “/usr/share/doc”:

Unison-doc.txt
Unison-Help_Basic-concepts.txt
Unison-Help_Running-Unison.txt
Unison-Help_Tutorial.txt
Unison-Manual_usr-share-doc-unison.txt

Sobre o luckyBackup, o Help (F1) concentra o máximo de informações em um “Manual”, fartamente ilustrado, com 88 KiB de texto minucioso.

A resolver


Esse backup completo das 2 partições, — além de muito mais simples, — é o que fará mais sentido, quando for instalado um novo HDD interno de 1 Terabyte.

A ideia (por enquanto) é fazer o backup frequente das partições “E:\” e “F:\” para o novo HDD interno, — e periodicamente para o SSD externo.

Isso deverá substituir a rotina atual, — de clonar apenas algumas pastas escolhidas, — e por consequência, vai liberar espaço das partições “home1” e “home2”, praticamente duplicando a capacidade atual das partições de trabalho.

Além disso, várias pastas das partições “E:\” e “F:\”, — que não são de trabalho, mas apenas para guarda de acervos, — também poderão ser ser movidas para o novo HDD, com cópias no SSD.

Teoricamente, o novo HDD será mais rápido, — além de ser Sata3, — porém as portas da placa-mãe ainda são Sata2, o que limitará sua taxa de transferência.

Em geral, pensamos em usar sempre o HDD mais rápido, e relegar os HDDs mais lentos para tarefas secundárias, — mas cabe pensar se o backup se enquadra em “secundário”. — Fazer backup de 2 menores em 1 maior parece a coisa mais simples, ao passo que o inverso sempre depende de previsões (falíveis) sobre o provável crescimento de 2 grupos de pastas.

Sequência da reorganização



Pré-história


“Desde os tempos paleolíticos, o homem das cavernas…”

O primitivo Apple II+ (8bit), com 64KB RAM e apenas 1 “Floppy disk drive” (FDD) de 5¼’’, — onde precisava ser mantido o diskette com o sistema operacional, — adquirido em 1986, não alimentava luxos de backup. Mesmo com o segundo FDD (1987), o “espaço” para manobras era acanhado. No mínimo, implicava em tirar e colocar 2 diskettes, alternadamente, inúmeras vezes (se é que isso era possível; não lembro). Cada um, comportava 120 ou 130 KB (se não me engano). Com um furador de papel, podia-se abrir um “rasgo” na segunda lateral da “capa”, para permitir gravação do outro lado. Fechar esses “rasgos” laterais com uma etiqueta autocolante impedia nova gravação, por segurança.

Manobra especial, já com placa CP/M (1987), era carregar o sistema + aplicativo (dBase II, Wordstar, Calcstar), em seguida deletar o aplicativo, — mantendo o “overlay”, que continuava necessário, — e no espaço assim liberado, copiar arquivos do outro diskette, — que em seguida seria substituído por um terceiro, para gravar nele o backup. Pouca coisa chegava a merecer tanto esforço, — e de qualquer modo, nada pôde ser preservado, ao adquirir o PC-XT (1990), pela demora em migrar. — Corria a lenda de que, no Serpro, algum maluco ainda mantinha um esquema para cópia de diskettes Apple II+ / PC-IBM, mas não consegui localizar tal pessoa. Serviu de lição, para nunca mais ficar estacionado em um beco-sem-saída tecnológico. Cadastro de assinantes, aplicativos dBase II (gerador de etiquetas) etc. tiveram de ser impressos em papel, pelo Apple II+, — e digitados novamente, no PC-XT.

O PC-XT (16bit), com 640 KB RAM + HDD de 20 MB + 2 FPP (5¼’’ e 3½’’), a partir de 1990, e seus sucessores 286, 486 e Pentium II deixaram muito mais backups, — arquivos Xerox Ventura Publisher, MS-DOS Word, WinWord, dBase III, AutoCAD etc., — que permaneceriam compatíveis até hoje, se ainda houvesse aparelhos de Floppy no mercado. A lição aprendida fez migrar, o quanto antes, para “discos ZIP” (Iomega Zip Disk), e em seguida para CD. O que ainda se aproveita, há muito tempo já está em HDD, — com backup em outro HDD, e agora também no SDD (além dos CDs / DVDs intermediários). É um acervo “morto”, fixado no tempo, — exceto pelas muitas conversões e edições que já foram feitas, desde então, e que não há motivos para descartar, sob pena de algum dia precisar reconverter e reeditar a partir dos originais. Isso inclui, também, um conjunto de “macros” do Word (guardados em “c/users/ flavio/ Application Data/ Microsoft/ Modelos/ normal.dot” do Wine). A conversão também depende do Wordpad, único aplicativo encontrado até agora, capaz de identificar (e substituir) a codificação do “á” minúsculo do MS Word / Xerox Ventura Publisher, — salvo algum comando cabalístico do Linux, que ainda não descobri.

Uma terceira “camada geológica” de backups é formada por quase 200 CDs / DVDs, usando (e às vezes misturando) 2 metodologias diferentes: — (a) Cópias de pastas ou subpastas completas, zipadas ou não, em diferentes momentos dos últimos 15 anos, abrangendo todo o conteúdo das partições de documentos do Windows, desde 2000; e (b) Cópias apenas dos arquivos modificados “desde o backup anterior”, localizados pela busca avançada do Explorer (CTRL-F) e zipados em massa, para preservar suas posições na “árvore” de pastas. — Lidar com tudo isso, diretamente, é um tal de “ejeta-CD-coloca-DVD” extremamente enjoado. Até uns 10 anos atrás, o DSearch (DiskSearch, Tenebree Software) ajudava. Depois, simplifiquei a vida, gerando TXTs com o conteúdo de cada disco, pelo comando (Windows) “dir h: /s > 097_CD_Label.txt”, — variando a numeração e a “label”. Uma busca por “string” no conteúdo, na pasta onde estão esses TXTs, localiza todos os backups de qualquer arquivo, cujos nomes mantêm certo padrão, ao longo do tempo. Aos poucos, os arquivos que interessam, foram sendo copiados para o HDD, e é cada vez mais raro precisar buscar mais alguma coisa nos antigos backups em CD / DVD.

História antiga


“Já na antiga Grécia…”

O luckyBackup foi instalado em 12 Mai. 2012, simultaneamente com o Komparator, Unison-gtk, Sitecopy e Krusader, escolhidos rapidamente, em uma busca no Synaptic, para ver qual atendia melhor. A primeira “tarefa” do luckyBackup foi configurada às 13:55, e a cópia inicial se completou em 14 minutos. Foram configuradas mais algumas “tarefas”, padronizando as opções, e registrei que ele colocava arquivos ocultos nas pastas das partições Fat32 (Windows). Uma anotação da época fala em um “controle”, visto de passagem, que talvez evitasse isso, mas pode ter sido só impressão. Hoje, não encontro arquivos ocultos do luckyBackup nas partições Fat32 (provavelmente, só ocorre quando a “sincronização” é feita nos dois sentidos). Também ficou clara a necessidade de assegurar a prévia montagem das partições envolvidas, — automaticamente, ou à mão. Um relato bastante resumido foi publicado em 14 Mai. 2012.

Naquele momento, ainda imaginava a possibilidade de editar os mesmos arquivos, indiferentemente, tanto nas partições do Windows quanto na “/home” do Kubuntu (Home1), — por isso, adotei a opção de sincronizar as pastas de documentos nos 2 sentidos.

Na prática, isso impunha backups excessivamente frequentes, — já que o Windows não podia acessar a partição “/home” do Kubuntu, em busca de alguma alteração feita poucas horas antes, — além do risco de fazer alterações em ambas as cópias de um mesmo arquivo, inadvertidamente, e a última alteração sobregravar a outra, ao disparar o backup. Mas o mais chato, era no final do Horário de verão, — quando as horas das duas cópias se desencontravam, — a menos que fizesse uma alteração no Windows, que não me animei a tentar. É possível que tenha feito alguma alteração nos dois Linux (este ano, o Linux Mint 17.3 foi flagrado fora do padrão UTC, mas não sei se “herdou” isso de alguma coisa feita em 2012, ou se foi burrice durante a instalação, em 2016).

Em 19 Ago. 2012, o luckyBackup foi completamente(?) removido, e reinstalado, — nenhuma anotação do motivo. — Ao abrir novamente, as antigas “tarefas” apareceram intactas, porém eu havia deletado as pastas da “Home1” (Kubuntu), por motivos que também não anotei. Foi criado um novo “perfil”, e nele recriadas as “tarefas”, apontando para novas pastas.

O Unison-gtk 2.40.65 foi utilizado regularmente de Set. 2012 até Ago. 2014, — ou seja, na “vigência” do Kubuntu 12.04, — com um intervalo entre Fev. e Ago. 2013, de acordo com “~/.unison/unison.log”.

É possível que as “tarefas”, — alternando “perfis” manualmente, — fossem disparadas ao final de determinados trabalhos, cujos arquivos considerava mais importantes. Em 10 Set. 2012, foram sincronizadas 7 pastas, — mas no dia 14, apenas uma, com textos referentes aos séculos XVIII e XIX. Em 20 Out. 2012, apenas 2 pastas, ambas sobre as locomotivas live-steam do Deo Espírito Santo, — mas em 24 Out., nada menos que 9 pastas, talvez percorrendo manualmente todo o conjunto de “tarefas”, com material acumulado. Mas é difícil ter certeza.

Em 1º Ago. 2013, voltei a substituir o luckyBackup pelo Unison. — Nenhuma anotação sobre o motivo, — apenas, que deletei as pastas anteriores, e criei outras, com nomes diferentes, em outro “local” da “Home1”.

Em 24 Ago. 2014, foi feito upgrade do Kubuntu 12.04 para 14.04. Três semanas depois, em 13 Set. 2014, acabei decidindo reinstalar o Kubuntu 14.04, — e a lista de pacotes instalados em seguida, pelo Synaptic, começa pelo Unison-gtk. Só que, não funcionou. Em 1º Out. 2014, há várias anotações de uma tentativa de decifrar o mistério (permissões, path etc.), sem resultado.

A impossibilidade de mergulhar no estudo, — isso não era a única coisa a exigir pesquisa e leitura, às voltas com a migração para o Kubuntu 14.04, — fez com que o problema se arrastasse por mais 2 meses (120 dias sem backup automatizado). Em 1º Dez. 2014, o Unison-gtk foi reinstalado e removido completamente, nada menos que 3 vezes. Em seguida, o luckyBackup voltou a ser instalado, removido completamente, e reinstalado, — e voltou a ser usado, desde então.

Quase todos os logs hoje existentes em “~/.luckyBackup/” são de 1º Dez. 2014, — exceto dois, datados de Set. e Mai. daquele ano. — [Também há um “luckyCron.txt” mais antigo, de 14 Mai. 2012. — De 2016, apenas um “default.profile” em branco (0 B), de 24 Abr., quando foi instalado o atual Kubuntu 16.04; e um “settings.ini” de 6 Jun., embora tenha feito inúmeros backups depois desse dia].

Ainda em Dez. 2014, foi feita uma “limpeza” de dezenas (ou centenas?) de arquivos ocultos nas partições do Windows, infelizmente não documentados (o Windows localizou e deletou sem dificuldade). Se isso era necessário, até hoje não sei. No próprio Kubuntu 14.04, em 20 Dez. 2014, também foram deletados outros arquivos ocultos, — um conjunto para cada “tarefa”. As anotações da época são resumidas demais, e pouco esclarecem:

Removido todos os dados antigos do registro instantâneo
Removendo /root/.luckyBackup/snaps/default-site VFCO-20141219081905.changes.log
Removendo /root/.luckyBackup/logs/default-site VFCO-20141219081905.log
Removido todos os dados antigos do registro instantâneo
Removendo /root/.luckyBackup/snaps/default-workflow VFCO-20141219081922.changes.log
Removendo /root/.luckyBackup/logs/default-workflow VFCO-20141219081922.log
(etc.)

Parece que a partir de 20 Dez. 2014 o problema ficou resolvido, — e não cometi mais burradas, — mas é uma pena não ter anotações claras do quê possa ter aprendido a não fazer (se é que aprendi), para assegurar que não volte a fazer no futuro.

Em 1º Ago. 2015, foi instalado um segundo Kubuntu 16.04 LTS no lugar de “Linux2”, — absolutamente igual ao “Linux1”, exceto por ser “i386” (enquanto o “principal” era “amd64”), — e imediatamente foi instalado o luckyBackup, também nele (por hábito). Porém, acredito que nunca foi colocado em uso.

Entre 20 e 27 Jan. 2016, chegou a ser usado um segundo luckyBackup, — instalado no Linux Mint 17.3, — para sincronizar apenas 2 pastas, que não faziam parte do backup regular pelo Kubuntu.

Em 12 e 13 Fev. 2016, foram alteradas as “etiquetas” (Label) das partições Fat32, — e editadas as “tarefas” do luckyBackup, simplificando o “path” nos comandos, — que até então usavam identificadores UUID, incômodos de decifrar, no meio de qualquer tarefa.

Não lembro de qualquer problema, ao instalar o Kubuntu 16.04, em 24 Abr. 2016, e novamente o luckyBackup, no mesmo dia. — Naquele momento, tudo já estava sendo minuciosamente registrado em centenas de PrintScreen, TXTs etc. (se houve algo digno de nota, vai acabar aparecendo).

De 1º a 28 Mai. 2016, o Windows XP começou a ser “evacuado”, — pela eliminação sistemática de grupos de arquivos, tanto em “C:\” (programas desinstalados), quanto em “F:\” (velhos Photoshop), — e sucessivos esvaziamentos da Lixeira, devidamente documentados. Ao final, foi rodado o luckyBackup (após mais algumas verificações), para liberar espaço também na “Home1”.

Felizmente, o Windows pôde ser eliminado, em 29 Mai. 2016, e agora todos os Linux seguem o padrão de hora UTC no sistema, — só tinha “estragado” a configuração do Mint 17.3, mas o Debian tanto reclamou, que o erro foi percebido e corrigido. — Fato é que o luckyBackup continua funcionando bem, até hoje.

Sequência da reorganização



___________
• Backups realizados em 29 e 30 Nov. 2016, no Kubuntu 16.04 LTS, com uma pequena ajuda do Linux Mint 18 KDE.
• Levantamento, relato, tratamento de imagens e publicação inicial em “Live DVD” (Pendrive 8GB) Knoppix 7.7.1, nos dias 2 a 4 Dez. 2016.
• Uma chuva com relâmpagos e risco de eventual queda da rede elétrica, na tarde de 4 Dez., fez encerrar a sessão “Live DVD” (Pendrive 8GB) Knoppix 7.7.1, e prosseguir no Kubuntu 16.04 LTS, instalado no HDD.

— … ≠ • ≠ … —

Ferramentas &tc.


Postado por Mboaba às sábado, dezembro 03, 2016 0 comentários
Marcadores: , , , , , , , , , , , , , ,

domingo, 3 de julho de 2016

Conky - configuração em andamento

Conky no Kubuntu 17.04 Zesty Zapus daily-build (“development branch”).

Este relato foi publicado em 3 Jul. 2016, — e recebeu as seguintes atualizações:

  • Conexão de rede (29 Jul. 2016)
  • Reorganização II (30 Jul. 2016)
  • Reorganização III (31 Out. 2016)

Configuração simples para um Conky funcional

3 Jul. 2016 - Esta é uma configuração “em trânsito”, — originária do Kubuntu 14.04 (Conky 1.9), e adaptada ao Kubuntu 16.04 Xenial, ao Debian testing “Stretch”, ao KDE Neon (Conky 1.10), — porém merece uma “migração” mais completa, depois que também o Linux Mint 17.3 for substituído pelo Linux Mint 18.

Começou com um arquivo de configuração encontrado na web, e modificado como forma de aprendizagem, — até conseguir que o Conky exibisse (quase) todas as informações desejadas, em um formato leve e discreto, para se manter visível na tela quando o Psensor e o KSysguard são ocultados por outros aplicativos, ou minimizados.

Ainda não foi convertida para a nova sintaxe recomendada pelo Conky 1.10 (ver “Parâmetros e sintaxe”, abaixo), nem para o “Lua”, — exceto em alguns pontos específicos, onde alguma conversão precisou ser feita em caráter emergencial.

Alguns trechos, — p.ex.: “Connections”, “Network”, temperadura de HDD, — até agora não funcionam, por isso estão desabilitados (“#”), e permanecem como lembretes. No fundo, não eram prioridade. Se fizessem muita falta, talvez já estivessem resolvidos.

Enfim, não tenho certeza absoluta de que todos os números exibidos pelo Conky estejam corretos, — o que é um motivo para continuar de olho no Psensor e no KSysguard, onde as informações são escandalosamente evidentes, — embora frequentemente ocultados por outros aplicativos, e minimizados a maior parte do tempo.

Alterações do Conky no Debian, em 21 Jun., quando as partições receberam Rótulos (Label) mais racionais

Essa configuração vem sendo modificada com frequência, — ora no Kubuntu, ora no Mint Cinnamon, no KDE Neon, ou no Debian testing “Stretch”, — e, depois de “aprovadas”, as alterações são aplicadas nos demais, para manter uma padronização.

Uma estrutura sistematizada facilita a edição rápida do arquivo “.conkyrc”

Ontem (Sáb., 2 Jul. 2016), o arquivo “.conkyrc”¹ foi copiado da “home” do Debian testing “Stretch”, e colado na “home” (virtual) do Live USB Linux Mint 17.3 KDE, — onde já passou por meia-dúzia de ajustes e correções, à medida em que algumas falhas foram percebidas.

(¹) Lembrando que arquivos começando por ponto (“.”) são invisíveis, por default. Para localizá-lo, é necessário acionar a opção “exibir arquivos ocultos”.

Aqui, o “${alignc}”, colocado antes de abrir a formatação das fontes usadas na Hora e na Data, não deu certo. — Movi o alinhamento para dentro das tags de fontes de Hora e Data (como já havia feito no Kubuntu 16.04), e resolveu, — mas ainda foi necessário eliminar um espaço vazio que havia no final de ambas as linhas, perturbando a centralização.

Hoje (Dom., 3 Jul. 2016), foi introduzida mais uma inovação, — “K /home” virou “K /home1”; e “M /home” virou “M /home2”, para maior clareza, — e mais tarde isto será propagado para os 4 Linux instalados.

Live USB Linux Mint 17.3 KDE

Arquivo “.conkyrc” no Dom. 3 Jul. 2016, às 13:13


O arquivo “.conkyrc” compõe-se de 2 partes, — uma seção de parâmetros para controle geral da aparência e funcionamento, — e uma seção (“TEXT”) com os itens a serem exibidos, incluídas configurações específicas de alinhamento, cor, tamanhos e fontes de letra.

Repetindo: — Este arquivo ainda não foi convertido para a sintaxe atual, exceto em alguns pontos.

Xft → permite substituir a fonte padrão (monoespaced) por qualquer fonte de letra disponível no sistema.

Window e Double buffering → esses controles ajudam a contornar alguns problemas na exibição, como tremedeira etc. — Caso ocorram, pesquise no Google por estas 3 palavras + Conky.

Foi escolhido posicionamento inferior esquerdo (bottom_left), sem cercadura (border), porém com margens laterais e verticais (gap_x, gap_y).

Na segunda parte (“TEXT”), observe que ainda há várias linhas desabilitadas, — começando por “#”, — como lembrete de itens que ainda não funcionaram, a serem pesquisados.
# Use Xft?
use_xft yes
xftfont verdana:pixelsize=10
xftalpha 0.8
text_buffer_size 2048

# Update interval in seconds
update_interval 1

# This is the number of times Conky will update before quitting.
# Set to zero to run forever.
total_run_times 0

# Create own window instead of using desktop (required in nautilus)
own_window yes
own_window_transparent yes
own_window_type normal
own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager

# Use double buffering (reduces flicker, may not work for everyone)
double_buffer yes

# Minimum size of text area
minimum_size 250 250
maximum_width 250

# Draw shades?
draw_shades no

# Draw outlines?
draw_outline no

# Draw borders around text
draw_borders no

# Draw borders around graphs
draw_graph_borders yes

# Stippled borders?
stippled_borders 0

# border margins
border_margin 1

# border width
border_width 0

# Default colors and also border colors
default_color white
#default_shade_color black
#default_outline_color black
own_window_colour 000000

# Text alignment, other possible values are commented
#alignment top_left
#alignment top_right
alignment bottom_left
#alignment bottom_right

# Gap between borders of screen and text
# same thing as passing -x at command line
gap_x 10
gap_y 40

# Subtract file system buffers from used memory?
no_buffers yes

# set to yes if you want all text to be in uppercase
uppercase no

# number of cpu samples to average
# set to 1 to disable averaging
cpu_avg_samples 2

# number of net samples to average
# set to 1 to disable averaging
net_avg_samples 2

# Force UTF8? note that UTF8 support required XFT
override_utf8_locale yes

# Add spaces to keep things from moving about? This only affects certain objects.
use_spacer none

own_window_argb_value 0
own_window_argb_visual yes

TEXT
${font verdana:pixelsize=32}Mint KDE${font}
${font verdana:pixelsize=10}${hr 2}${font}
${font verdana:size=32}${alignc}${time %H:%M}${font}
${font verdana:pixelsize=18}${alignc}${time %a, %d %b. %Y}${font}
${font verdana:pixelsize=10}
${alignr}Duração
${color}${alignr}${uptime}
${color Yellow}Sistema ${hr 2}${color}
${alignr}${nodename}
${execi 60 lsb_release -d} (${execi 60 lsb_release -c -s})
Kernel ${sysname} ${kernel}

${color Yellow}Recursos ${hr 2}${color}

${cpugraph cpu1 30,110} ${alignr}${cpugraph cpu2 30,110}
CPU1: ${cpu cpu1}% ${alignr}CPU2: ${cpu cpu2}%${alignr}

Mem ${mem}/${memmax}${alignr}${membar 10,60}
Swap ${swap}/${swapmax}${alignr}${swapbar 10,60}
#Receiving ${downspeedf wlan0} KB/s ${alignr}${downspeedgraph wlan0 10,60}
#Total Received${alignr}${totaldown wlan0}
#Sending ${upspeedf wlan0} KB/s ${alignr}${upspeedgraph wlan0 10,60}
#Total Sent${alignr}${totalup wlan0}

CPU Temp ${alignr}${hwmon 0 temp 1}Cº
MB Temp ${alignr}${hwmon 0 temp 2}Cº
Core0 Temp ${alignr}${hwmon 1 temp 2}Cº
Core1 Temp ${alignr}${hwmon 1 temp 3}Cº
Fan ${alignr}${hwmon 0 fan 1} rpm
#HDD ${alignr}${hddtemp /dev/sda}°C
#HDD ${alignr}${hddtemp /dev/sdb}°C

Buffers ${alignr}$buffers
Cache ${alignr}$cached
Memória livre ${alignr}${memfree}
Memória disp. ${alignr}${memeasyfree}
#
#Connections: ${tcp_portmon 1 65535 count}
#Active Interface ${alignr}$gw_iface
#
#Networking:
# Down: ${downspeed eth0} k/s ${offset 70}Up: ${upspeed eth0} k/s
#${downspeedgraph eth0 32,150} $alignr${upspeedgraph eth0 32,150}
#
$hr
Frequency (in MHz): ${alignr} $freq
Frequency (in GHz): ${alignr} $freq_g
CPU Usage:$color $cpu% ${cpubar 4}
$hr
Uso ${alignr}PID CPU Mem
${alignr}% %
${top name 1} ${alignr}${top pid 1} ${top cpu 1} ${top mem 1}
${top name 2} ${alignr}${top pid 2} ${top cpu 2} ${top mem 2}
${top name 3} ${alignr}${top pid 3} ${top cpu 3} ${top mem 3}
${top name 4} ${alignr}${top pid 4} ${top cpu 4} ${top mem 4}
${top name 5} ${alignr}${top pid 5} ${top cpu 5} ${top mem 5}
${top name 6} ${alignr}${top pid 6} ${top cpu 6} ${top mem 6}
${top name 7} ${alignr}${top pid 7} ${top cpu 7} ${top mem 7}
${top name 8} ${alignr}${top pid 8} ${top cpu 8} ${top mem 8}

${color Yellow}File Systems ${hr 2}${color}

E:\ ${alignr}${fs_used /media/mint/E} / ${fs_size /media/mint/E} ${alignr}${fs_bar 10,60 /media/mint/E}
F:\ ${alignr}${fs_used /media/mint/F} / ${fs_size /media/mint/F} ${alignr}${fs_bar 10,60 /media/mint/F}
K /home1 ${alignr}${fs_used /media/mint/Home1} / ${fs_size /media/mint/Home1} ${alignr}${fs_bar 10,60 /media/mint/Home1}
M /home2 ${alignr}${fs_used /media/mint/Home2} / ${fs_size /media/mint/Home2} ${alignr}${fs_bar 10,60 /media/mint/Home2}
$hr
Linux1 Kubuntu ${alignr}${fs_used /media/mint/Linux1/} / ${fs_size /media/mint/Linux1/} ${alignr}${fs_bar 10,60 /media/mint/Linux1/}
Linux2 Mint ${alignr}${fs_used /media/mint/Linux2/} / ${fs_size /media/mint/Linux2/} ${alignr}${fs_bar 10,60 /media/mint/Linux2/}
Linux3 Debian ${alignr}${fs_used /media/mint/Linux3/} / ${fs_size /media/mint/Linux3/} ${alignr}${fs_bar 10,60 /media/mint/Linux3/}
Linux4 Neon ${alignr}${fs_used /media/mint/Linux4/} / ${fs_size /media/mint/Linux4/} ${alignr}${fs_bar 10,60 /media/mint/Linux4/}

Origem


Configuração postada por Panicuzz no KDE-Look em fins de 2014

Ao instalar o Conky, ele não traz um arquivo de configuração “.conkyrc”¹, — e se você mandar executar “conky”, não vai aparecer nada na tela. — Portanto, você deve criar seu próprio arquivo de configuração, ou adaptar algum arquivo encontrado pronto, e salvá-lo na “home”.

(¹) Lembrando que arquivos começando por ponto (“.”) são invisíveis, por default. Para localizá-lo, é necessário acionar a opção “exibir arquivos ocultos”.

Ainda sem fazer a menor ideia de como escrever um arquivo “.conkyrc”, no final de Abril, foi utilizada uma configuração publicada por Panicuzz no KDE-Look, em fins de 2014, e que hoje não está mais no site.

Fontes (.ttf), configuração, logo KDE e “preview” postados por Panicuzz

O arquivo comprimido trazia, — além da configuração, — uma fonte ou conjunto de fontes de letra “Acens” (.ttf), uma logomarca Kubuntu e uma imagem “preview” do resultado.

Foi utilizada apenas a configuração, — renomeada de “KDE Conky 2xcore” para “.conkyrc” e colada na “home” do Kubuntu 16.04, — e a partir daí começaram as edições, tateando por tentativa-e-erro, para ver os resultados.

Em geral, basta “salvar” o arquivo “.conkyrc”, — após cada alteração, — para o Conky piscar e reaparecer atualizado.

Outras vezes, — como agora em Live USB Linux Mint 17.3 KDE, — é preciso “parar” ou “matar o processo” Conky, e chamá-lo de novo em seguida.

Isso pode ser feito rapidamente por esse comando:

killall conky && conky

Resultado:

mint@mint:~ > killall conky && conky
Conky: /home/mint/.conkyrc: 44: no such configuration: 'border_margin'
Conky: desktop window (1e002af) is subwindow of root window (7d)
Conky: window type - normal
Conky: drawing to created window (0x1200002)
Conky: drawing to double buffer

Infelizmente, nesta sessão Live USB Linux Mint 17.3 KDE, o Conky torna a desaparecer, ao fechar o Terminal, depois disso. — Mas não, se o comando for dividido em 2 partes: — “killall conky”, e depois “conky”, — o que não deixa de ser útil, nas circunstâncias.

O primeiro trabalho sistemático, a partir do final de Abril, foi eliminar o excesso de cores, — até ficarem apenas 3 linhas amarelas, com “régua horizontal” reforçada (“${hr 2}”). — Em seguida, as fontes de letra foram substituídas por Verdana, usando busca-e-troca global no Kate.

Mais tarde, isso foi simplificado, com uma “declaração global” de fonte, — “${font verdana:pixelsize=10}” (que ainda aparece repetida, e talvez possa ser simplificada mais um pouco). — Apenas no cabeçalho existem 3 linhas com tamanhos diferentes de fonte, a exigir “declarações localizadas”, abertas e fechadas ali mesmo.

Uma das últimas alterações “globais” foi eliminar o negrito (bold) geral, — e constatar que as letras Verdana normais são suficientemente legíveis, sem necessidade de sobrecarregar a aparência do conjunto.

Reorganização inicial (I)


Conky, Psensor e KSysguard ao final do Domingo, 3 Jul. 2016, no Live Linux Mint 17.3 KDE

Os gráficos de CPU1 e CPU2 foram reorganizados lado a lado, ampliando sua altura, com economia de espaço vertical.

Os parâmetros “30,110” oferecem uma altura bastante razoável (30 pixels), e comprimento confortável dentro da largura total de 250 pixels (menos 10 pixels da margem da tela “gap_x”).

A linha de “CPU Usage”, mais embaixo, posteriormente foi deslocada para junto desses gráficos, e centralizada. — ver Reorganização II, no final.

As linhas de Buffer, Cache, Memória Livre e Memória disponível também acabaram por ser eliminadas, — desinteresse pessoal nesses detalhes, por enquanto. — ver Reorganização II, no final.

As tabelas de uso de CPU e Memória, pelos programas, também foram reunidas em uma só, — “código” já encontrado pronto na web, — o que permite mostrar até 8 “processos”, também com economia de espaço vertical.

Não existe vantagem em exibir a Frequência 2 vezes, — em MHz e em GHz. — Para ser franco, é algo que nunca me interessou, e poderia tranquilamente desabilitar ambas, se vier a precisar de espaço vertical para outras coisas.

Visão compacta das partições, no “Monitor do sistema” (gnome-system-monitor) do Linux Mint 17.3 Cinnamon

De um ponto de vista estritamente pessoal, a seção mais necessária é a de uso de espaço nas partições, — “E”, “F”, e seus backups “home1” (Kubuntu), e “home2” (Mint Cinnamon), — Não é nada que ameace “explodir” de uma hora para outra, mas é sempre chato esquecer esse detalhe, por 6 meses, ou 1 ano, — e, de repente, ter de tomar providências urgentes. Convenhamos que o espaço total não é nenhum latifúndio inesgotável.

Também é verificado com frequência o espaço ocupado nas partições de sistema dos 4 Linux, — para fins de acompanhamento e análise.

Por isso, essa tem sido a seção mais editada até o momento, — oferece informações de interesse permanente, que só encontro reunidas no “Monitor do sistema” do Cinnamon (gnome-system-monitor), e não no “Monitor do sistema” KDE (KSysguard), — porém sem a facilidade do Conky para ajustar à vontade, separando as partições de Sistema e de Documentos, e colocando-as na ordem “lógica” mais adequada. — Obs.: Mais tarde, foi constatado que o KSysguard permite, sim, criar novas abas, inclusive esta, com possibilidade de escolher as partições a serem exibidas, e os detalhes: espaço total, espaço ocupado, espaço livre, percentual de ocupação etc.

Conky com gráficos elípticos, por kralis-dm

Enfim, muitas outras coisas são possíveis, com grande facilidade, — p.ex., gráficos (dinâmicos) circulares ou elípticos, ao invés de barras retangulares.

Pessoalmente, minha opção é pela otimização do espaço na tela, à moda de “A invenção da laranja” (após tentar fazê-las quadradas), de Fernando Sabino.

Conky ainda em “Verdana bold”, no início; e plasmoide “Weather”, mais útil do que qualquer arranjo no Conky

Clima (“Weather”) também não me atrai, — no Kubuntu, uso um “applet” ou “plasmoid”, mil vezes mais completo e útil do que qualquer arranjo complexo do Conky (e sem nenhum trabalho). — Infelizmente, no KDE Neon e no Debian KDE, este “widget” encontra-se bastante empobrecido.

Os objetivos são muito mais de monitoramento, do que de ornamentação.

Embora os dados do Conky fiquem menos evidentes do que no Psensor e no KSysguard, tendem a permanecer mais visíveis, — mesmo em Capturas de tela que, a princípio, não visavam registrar tais informações, especificamente, — e muitas vezes já foram úteis mais tarde, no exame retrospectivo de algum evento.

Parâmetros e sintaxe


Novo modelo de configuração, incluído na ampla documentação do Conky 1.10 instalado no Xenial

Quanto ao “funcionamento” dos parâmetros usados em “modelos” baixados da web, a experiência logo deixou claro que nem sempre é garantido. — E existem pelo menos 2 motivos, que têm exigido pesquisa e alteração:

  • Sintaxe ultrapassada, usada em inúmeros “modelos”, — nem tão antigos assim, mas que deixou de funcionar, e precisou ser atualizada, a partir do Conky 1.10, que é o encontrado nos repositórios do Kubuntu 16.04 Xenial. — Um passo fundamental, daqui para frente, deve ser a reformulação completa, para o “modelo” de sintaxe mais “estruturada”, documentado na própria instalação no computador.

  • Parâmetros específicos de hardware, que precisam ser adaptados. — Afinal, existem tantas variedades e combinações de hardware, que se torna improvável encontrar “modelos” ajustados a qualquer computador específico. — Foi particularmente útil o “tutorial” Conky and system temperatures, de Pouletic, no BunsenLabs.

(in)Felizmente, os resultados obtidos, tateando desse modo empírico, foram tão satisfatórios, que não houve urgência de “estudar” mais a fundo, — por isso, não há como “ensinar”, até porque a variedade de hardwares comporta uma enciclopédia, — e um relato detalhado desse “bate-cabeça” seria mais tedioso do que útil. — Basta ver quão capenga a configuração continua, depois de 2 meses.

Em suma, vários problemas, dificuldades ou simples melhorias foram solucionados por dicas encontradas prontas, pesquisando na web. — Existem dúzias de sites com milhares de “modelos” prontos, além de milhões de fóruns e tutoriais onde você pode encontrar trechos de “código” para todo tipo de adaptação de detalhes. — A questão é atentar para a data em que essas dicas foram postadas, e sempre conferir a sintaxe atual. — E testar. Muitas vezes, dá certo logo de cara.

Exemplos da documentação instalada com o “conky-all” (1.10)

Porém, vários problemas e dificuldades acabaram sendo solucionados pela leitura da documentação instalada com o próprio Conky, na pasta “/usr/share/doc/conky-all/”.

Essa documentação também pode ser consultada e/ou baixada da internet, — mas este não parece um bom caminho pois, além de trabalhoso encontrar, sempre fica a dúvida sobre sua atualidade / compatibilidade:

Conky documentation (1.8.1…!)


Requisitos e montagem


Conjunto de pacotes úteis, mesmo em sessões Live USB

A primeira instalação experimentada, em fins de Abr. 2016, foi a do “conky-std” (padrão), — mas no mesmo dia acabou removida e substituída pela do “conky-all”, — mais completo (por via das dúvidas):

conky-std

This package should be a good compromise for most users that do not need special features. It includes the following support:

 X11, XDamage, XDBE, Xft, MPD, MOC, math, hddtemp, portmon, wireless, ncurses, ALSA mixer, apcupsd, I/O stats, argb and Lua.

conky-all

This is a full conky with most compile options enabled:

 X11, XDamage, XDBE, Xft, MPD, MOC, math, hddtemp, portmon, RSS, Weather, wireless, IBM, nvidia, eve-online, Imlib2, ALSA mixer, apcupsd, I/O stats, argb, Lua and the cairo and imlib2 lua bindings, Audacious, and XMMS2.

Final do relatório e opções do comando “sudo sensors-detect”

Entre Psensor e Conky, ignoro exatamente o quê é requisito para o quê. — Na dúvida, adotei um conjunto-padrão de pacotes e procedimentos, para não perder tempo:

  • Synaptic → psensor, lm-sensors, hddtemp, fancontrol
  • Synaptic → conky-all, curl
  • No terminal → sudo sensors-detect

Várias vezes já tive a impressão (ou confirmação?) de que nem tudo isso faz falta, na realidade. — Mas, até agora, nada disso parece ter prejudicado, — e não sei se compensa priorizar um estudo aprofundado, neste momento, apenas para eliminar algum pacote da lista.

Ao rodar “sudo sensors-detect”, obtêm-se algumas informações, ao final da verificação, que podem ser muito úteis.

Enfim, alguns parâmetros que não vinham corretamente configurados, — em nenhuma dica ou “modelo” encontrado na web, — acabaram sendo encontrados, por tentativa-e-erro, testando as variáveis do sistema.

Essas variáveis foram encontradas na pasta /sys/class/hwmon/ (monitoramento de hardware), — testadas sucessivamente no “.conkyrc” (seguindo alguma lógica, claro), — e os resultados comparados com os exibidos pelo KSysguard ou pelo Psensor, para conferir:
flavio@linux2:/home > cd /sys/class/hwmon/

flavio@linux2:/sys/class/hwmon > ls -1
hwmon0
hwmon1

flavio@linux2:/sys/class/hwmon/hwmon0 > ls -1
device
fan1_input
fan1_label
fan1_max
fan1_min
fan2_input
fan2_label
fan2_max
fan2_min
fan3_input
fan3_label
fan3_max
fan3_min
in0_input
in0_label
in0_max
in0_min
in1_input
in1_label
in1_max
in1_min
in2_input
in2_label
in2_max
in2_min
in3_input
in3_label
in3_max
in3_min
name
power
subsystem
temp1_crit
temp1_input
temp1_label
temp1_max
temp2_crit
temp2_input
temp2_label
temp2_max
uevent

flavio@linux2:/sys/class/hwmon/hwmon1 > ls -1
device
name
power
subsystem
temp2_crit
temp2_crit_alarm
temp2_input
temp2_label
temp2_max
temp3_crit
temp3_crit_alarm
temp3_input
temp3_label
temp3_max
uevent
Não gosto de “vôo cego”, — tentar “navegar por comandos”, sem ver nada em volta de onde “estou”, e sem ver o conjunto, — por isso, é claro que a primeira providência foi examinar essas pastas no Dolphin.

Só depois, utilizei esses comandos, — seguidos de “> lista.txt”, — para obter tudo isso em arquivo de texto, — pois não teria cabimento, ficar espremendo os olhos para “ler” no Dolphin, e digitar, um por um.

flavio@linux2:/sys/class/hwmon/hwmon1 > ls -1 > lista.txt

Nem é preciso dizer que, depois disso tudo, continuei tão ignorante como antes, a respeito de todo esse maravilhoso universo das entranhas do hardware. — Porém, consegui que mais 2 ou 3 coisas passassem a funcionar no Conky.

••• Conexão de rede


Descoberta do parâmetro para Conexão de rede

29 Jul. 2016 - Uma postagem de Luis Medina, ontem, — “Más de 450 Comandos Linux que deberías conocer”, — chamou atenção para este comando:

cat /proc/net/dev - mostrar adaptadores de red y estadísticas

Testando no Kubuntu, deu este resultado:
flavio@linux1:~$ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:  802669    4519    0    0    0     0          0         0   802669    4519    0    0    0     0       0          0
enp1s0: 156196454  149403    0    0    0     0          0       166 17515351  121804    0    0    0     0       0          0
Foi feita, então, a experiência de substituir “wlan0” por “enp1s0”, nestas linhas logo no início do “.conkyrc”, — que estavam desabilitadas (“#”) por falta de funcionamento:

Mem  ${mem}/${memmax}${alignr}${membar 10,60}
Swap ${swap}/${swapmax}${alignr}${swapbar 10,60}
#Receiving ${downspeedf wlan0} KB/s ${alignr}${downspeedgraph wlan0 10,60}
#Total Received${alignr}${totaldown wlan0}
#Sending   ${upspeedf wlan0} KB/s ${alignr}${upspeedgraph wlan0 10,60}
#Total Sent${alignr}${totalup wlan0}

As linhas ficaram, então, com esta forma:

Mem  ${mem}/${memmax}${alignr}${membar 10,60}
Swap ${swap}/${swapmax}${alignr}${swapbar 10,60}
Receiving ${downspeedf enp1s0} KB/s ${alignr}${downspeedgraph enp1s0 10,60}
Total Received${alignr}${totaldown enp1s0}
Sending   ${upspeedf enp1s0} KB/s ${alignr}${upspeedgraph enp1s0 10,60}
Total Sent${alignr}${totalup enp1s0}

Efeito imediato ao salvar o arquivo “.conkyrc” alterado

O resultado foi imediato, — finalmente, o Conky do Kubuntu passou a exibir algumas estatísticas do uso da rede.

Resta investigar o outro parâmetro, — “lo” (sic), com apenas 2 letras!, — coisa complicada de se pesquisar no Google.

Resta, também, começar a aprender alguma coisa sobre WiFi, pois, — antes de querer algum indicador, — convém saber qual indicador interessa (se é que interessa).

Enfim, faltava reavaliar a “programação visual”, para que o título “Kubuntu 16.04” voltasse a ficar visível, contra a imagem de fundo (wallpaper).

••• Reorganização II


Reorganização (II) do Conky, no Debian testing “Stretch”

30 Jul. 2016 - Embora feliz por finalmente obter informações do uso da Rede, a forma como se apresentaram ainda não era satisfatória, — nem racional, diga-se de passagem. — Para um gráfico de oscilações deslizando no tempo, aquela altura de apenas 8 pixels estava muito acanhada.

Por outro lado, 2 gráficos altos, — empilhados, um em cima do outro, — consomem muito espaço na vertical. — E os dados numéricos, ensanduichados entre eles, também davam muito trabalho para encontrar e focalizar com a vista.

Foi experimentado, então, outro trecho de código que estava guardado como lembrete, — apenas desabilitado por “#” no início das linhas, — cuja principal virtude era colocar os 2 gráficos de barra com altura adequada, para melhor visibilidade; e dispostos lado a lado, para melhor aproveitamento do espaço:

# Down: ${downspeed eth0} k/s ${offset 70}Up: ${upspeed eth0} k/s
#${downspeedgraph eth0 32,150} $alignr${upspeedgraph eth0 32,150}

O primeiro passo foi substituir “eth0” por “enp1s0”. — Em seguida, ajustar os 2 gráficos de barra para o mesmo padrão “30,110”, já utilizado para CPU1 e CPU2, — 30 pixels de altura, e larguras compatíveis com a “janela” de 250 pixels (menos 10 pixels da margem da tela “gap_x”).

Enfim, substituir o “${offset 70}”, — espaçamento na base do “casuísmo” (serviço porco), — por um alinhamento simples e “correto”, à direita:

Down: ${downspeed enp1s0} k/s ${alignr}Up: ${upspeed enp1s0} k/s
${downspeedgraph enp1s0 30,110} $alignr${upspeedgraph enp1s0 30,110}
Total ${totaldown enp1s0} ${alignr}Total ${totalup enp1s0}

Ainda não é o ideal, — agora, entra “em observação”, por uns tempos, — mas já melhorou 99%.

Para “enxugar o gasto” de espaço vertical, a antiga linha de “uso de CPU”, — que estava deslocado lá embaixo, com as 2 leituras da Frequência (em MHz e GHz), — foi levada para junto de CPU1 e CPU2.

Para compor o conjunto, — sem confundir a vista, — essa linha foi centralizada; — a palavra “Usage” foi eliminada; — e o percentual numérico foi passado para a direita do gráfico.

De “CPU Usage:$color $cpu% ${cpubar 4}”, o código passou a ser “${alignc}CPU   ${cpubar 8,120}   $cpu%”, — com separação por 3 espaços em branco, em cada lado do gráfico.

Opções em estudo para destacar CPU de CPU1 / CPU2

Pode-se reduzir o comprimento do gráfico para 90 pixels, de modo a destacar melhor essas legendas laterais, em relação à linha de cima. — Ou manter / ampliar o comprimento do gráfico, porém com uma linha em branco para melhor destacar dos gráficos CPU1 e CPU2, logo acima. — Esta última, parece a melhor opção.

Mais ajustes


De pouca evidência, — mas excelente resultado, no conjunto, — foi a redução de inúmeras barras “10,60” para “8,60” (busca-e-troca automática), para “desgrudá-las” umas das outras, e “desentijolar” o conjunto. Os olhos agradecem.

  • 31 Out. 2016 - Atualmente, reduzido para “6,60”, para deixar tudo “legível”, com a máxima facilidade, num relance de vista.

Realce de espaços em branco no final das linhas, no Kate (e no KWrite)

Havia um espaço em branco após a hora e a data, — herdado sabe-se lá desde quando, — e que só tinha sido descoberto e eliminado, nos casos em que provocou distorção evidente, como no Live USB Linux Mint 17.3 KDE.

Para agilizar e “institucionalizar” o cuidado com esse tipo de detalhes, o Kate (Debian, Kubuntu) e o KWrite (KDE Neon) foram configurados para acusar espaços em branco no final das linhas.

Os “modos” do Kate / KWrite podem ajudar no trabalho de longa duração com todo tipo de codificações

Outras providências que podem ajudar, — em especial, para longas permanências no Kate / KWrite, fazendo experiências sem fim, — é substituir o fundo branco por outra cor menos ofensiva à vista (configurações); — e adotar o “modo” de trabalho “Script” (Ferramentas → Modo → Script → Lua).

Não havia necessidade da declaração “${font verdana:pixelsize=10}” na linha abaixo da hora, — que já fechou sua formatação específica com a declaração “${font}”, — bastava a linha em branco, para manter a separação.

Havia uma linha, — com a legenda “Duração”, — acima do tempo “uptime” da sessão, e que podia ser substituída, — com vantagem, — por um simples “up” antes dos valores numéricos.

Experimentando parâmetros do comando “lsb_release” no Kubuntu

Os comandos e parâmetros “${execi 60 lsb_release -d} (${execi 60 lsb_release -c -s})” causavam a desnecessária exibição da palavra “Description” antes do nome de cada Linux, — bem como a repetição de “(stretch)” no caso do Debian, — o que só não era mais evidente porque “estourava” a largura de 250 pixels (menos 10 pixels da margem da tela “gap_x”), sumindo à direita.

No caso do Debian, bastava “${execi 60 lsb_release -ds}”, para exibir a descrição completa, — com direito ao “Stretch”, entre parêntesis!

No caso do Kubuntu e do KDE Neon, o comando original foi mantido completo, — apenas acrescentando “s” de “short” ao “-d” de “description”:

${execi 60 lsb_release -ds} (${execi 60 lsb_release -c -s})

Desentulhar de inutilidades (resumir ao essencial), — e nunca utilizar “TUDO EM MAIÚSCULAS”, que tendem a ser menos legíveis, em bloco de texto, — facilita muito a leitura imediata, com o mínimo de esforço ou perda de tempo.

Um exemplo, foi a eliminação do bloco de Buffers, Cache, Memória livre e Memória disponível, — informações um tanto “abstratas” que, pessoalmente, pouco consultava. — Para não jogar fora trabalho já feito (e depois ter de repetir), as 4 linhas foram apenas desabilitadas, com “#” no início:

#Buffers ${alignr}$buffers
#Cache ${alignr}$cached
#Memória livre ${alignr}${memfree}
#Memória disp. ${alignr}${memeasyfree}

As “réguas horizontais” que ainda tinham dupla espessura, — “${hr 2}”, — foram reduzidas ao padrão, por não haver necessidade de sobrecarregar o visual.

O resultado dessas alterações é o que se segue:
TEXT
${font verdana:pixelsize=32}Debian Stretch${font}
${font verdana:pixelsize=10}${hr}${font}
${alignc}${font verdana:size=32}${time %H:%M}${font}
${alignc}${font verdana:pixelsize=18}${time %a, %d %b. %Y}${font}

${alignr}up ${uptime}
${color Yellow}Sistema ${hr}${color}
${alignr}${nodename}
${execi 60 lsb_release -ds}
Kernel ${sysname} ${kernel}

${color Yellow}Recursos ${hr}${color}

${cpugraph cpu1 30,110} ${alignr}${cpugraph cpu2 30,110}
CPU1: ${cpu cpu1}% ${alignr}CPU2: ${cpu cpu2}%

${alignc}CPU   ${cpubar 8,120}   $cpu%

Mem  ${alignr}${mem} / ${memmax}  ${alignr}${membar 8,90}
Swap ${alignr}${swap} / ${swapmax}  ${alignr}${swapbar 8,90}
#
#Buffers ${alignr}$buffers
#Cache ${alignr}$cached
#Memória livre ${alignr}${memfree}
#Memória disp. ${alignr}${memeasyfree}

CPU Temp ${alignr}${hwmon 0 temp 1}ºC
MB Temp ${alignr}${hwmon 0 temp 2}ºC
Core0 Temp ${alignr}${hwmon 1 temp 2}ºC
Core1 Temp ${alignr}${hwmon 1 temp 3}ºC
Fan ${alignr}${hwmon 0 fan 1} rpm
#HDD ${alignr}${hddtemp /dev/sda}°C
#HDD ${alignr}${hddtemp /dev/sdb}°C

#Connections: ${tcp_portmon 1 65535 count}
#Active Interface ${alignr}$gw_iface
#
Down: ${downspeed enp1s0} k/s ${alignr}Up: ${upspeed enp1s0} k/s
${downspeedgraph enp1s0 30,110} $alignr${upspeedgraph enp1s0 30,110}
Total ${totaldown enp1s0} ${alignr}Total ${totalup enp1s0}

Reorganização III


Conky alterado no Kubuntu 16.04 LTS

31 Out. 2016 - O particionamento do “novo disco” SSD externo segue mais ou menos o mesmo padrão adotado há vários anos: — partições primárias para instalação de sistemas Linux, e uma grande partição estendida para documentos.

De início, foi criada apenas uma partição primária, — para testar a instalação e uso diário de um primeiro sistema em “disco” portátil, — por isso, interessava acrescentar apenas 2 novas partições ao Conky de todos os sistemas instalados:

  • sdc1 → “Linux5”, — partição de sistema do Kubuntu 17.04
  • sdc5 → “Terabyte”, — nome da nova partição de dados, — que não “pertence” a nenhum Linux, em particular

Para o próprio Kubuntu 17.04 Zesty Zapus, foram acrescentadas estas 2 linhas ao arquivo “home/.conkyrc” padrão:

  • Terabyte ${alignr}${fs_used /media/flavio/Terabyte} / ${fs_size /media/flavio/Terabyte}  ${alignr}${fs_bar 6,60 /media/flavio/Terabyte}
  • Linux5 Zesty ${alignr}${fs_used /} / ${fs_size /}  ${alignr}${fs_bar 6,60 /}

Nos demais sistemas, a segunda linha precisava ser mais explícita:

  • Linux5 Zesty ${alignr}${fs_used /media/flavio/Linux5/} / ${fs_size /media/flavio/Linux5/}  ${alignr}${fs_bar 6,60 /media/flavio/Linux5/}

Utilização de “shades” para destaque das letras brancas onde a imagem de fundo é mais clara

Uma folhagem muito clara pela incidência do sol, na imagem de fundo (wallpaper), dificultava a leitura do texto do Conky, em letras brancas.

A solução foi ativar “shades”, — mais discreto do que “outlines”, — o que também deixou mais legíveis os textos menores.

O truque está no contraste, — se cor da letra é clara, destaca-se onde o fundo é mais escuro, — e o delineamento parcial em cor escura destaca-se onde o fundo é mais claro:

draw_shades yes

Utilização do “curl” para obter a previsão do clima

A volta a um velho “Bookmark” sobre o Conky acabou trazendo um “ganho extra”, — ainda não incorporado ao Conky (talvez nunca seja), mas esclarecedor dos usos e potencialidades do “curl”.

É pouco provável, encontrar espaço no Conky, — já, quase, chegando ao “teto” da tela, — mas informação útil nunca é demais.

De quebra, um espanto: — Até então, não havia lembrado de instalar o “curl”, — o que teve de ser feito depois, só para conferir essa dica.

Sinal de que ele não era realmente necessário para mais nada, — entre os usos atuais do Conky, — que já estava funcionando, normalmente, desde 2 dias antes.

Lição de casa: — Descobrir o que mais falta instalar, para o “curl” exibir a previsão do tempo

Ao tentar repetir a façanha no Terminal do Debian “testing”, outra descoberta: — Acontece, de o “curl” ser instalado, sem trazer automaticamente todo o necessário para exibir essa previsão do tempo. — Mas sabendo tudo isso, já fica fácil descobrir o resto.

_________
Relato publicado em Live USB Linux Mint 17.3 KDE, em 3 Jul. 2016.
••• Ampliado posteriormente no Kubuntu 16.04 LTS, no Linux Mint 17.3 Cinnamon, no KDE Neon, no Debian (stretch, jessie, testing), no Linux Mint 18 KDE e no Kubuntu 17.04 Zesty Zapus daily-build (“development branch”).

— … ≠ • ≠ … —

Ferramentas &tc.


Postado por Mboaba às domingo, julho 03, 2016 0 comentários
Marcadores: , , , , , , , , ,
Assinar: Postagens (Atom)